There are many more things I’m still concerned about. It’s that or never getting to actually do the release. But given the bug reporting dynamics and the availability of developers, I just don’t see any other way to handle this. That would be a quite horrible policy of dealing with bug reports. One possibility here is to declare amnesty for all bug reports filed against the current stable series and then reopen the ones that will be reproduced by users in the new release. Of those 4K+ bug reports and feature requests a whopping 624 bugs are crashers. They recently passed the 4K mark, which is, like, a 30% increase in just about a year. The situation with bugs in GIMP - and I’m sorry I have no other words for this - is getting out of hand. And that is the third important topic here. Which means that attempting to complete this API rewrite in time for the release will keep Jehan away from bug fixing. Just searching for ‘GimpRGB’ reveals almost 800 instances in the part related to user interface and over 400 instances in the backend code. My primary concern here is that getting and setting colors is something that happens in GIMP all the time, even if you don’t see it in the user interface. Most recently, GEGL itself got functions for getting and setting CMYK colors. Not to mention CMYK, HSV, HSL, and friends. So instead of functions like GimpRGB and GimpCMYK built right inside GIMP you get an exposure to all the color models available in GEGL and babl, and that’s a lot.īabl supports the entire CIE family of color models - LAB, LCH, YUV, XYZ - as well as newer things like OKlab. One of the ongoing changes here is the new API that helps make GIMP more omnivore in terms of color spaces and color models. I am not including API features on purpose in the freeze, because I think an additional month for the last little tweaks may be worth it Historically, this has been the number one reason for long, long development cycles in GIMP. This is something I’m actually more concerned about. The second important topic is API changes. I think it is feasible for ! :-)- November 21, 2023 Though the file format side will have to be stable (this can't change version after version for compatibility). Yeah, the GUI can be improved iteratively (as long as it's not *horrible* i.e. But judging by the response on Twitter the first possibility is more likely to happen which means a basic implementation in 3.0: We’ve been waiting for non-destructive editing for frigging 23 years since the beginning of the work on GEGL, two or three more months - it’s not too bad. In other words, the worst case scenario here is that GIMP 3.0 loses that bit of numerology where a release with a fancy number gets a fancy new feature. Or the developers will postpone this patch till version 3.0.2 that is expected to be released soon after 3.0. So there is a strong possibility that we will either end up with a basic implementation for 3.0 and then see more in the next updates. They thought about a lot of things, which is great.īut it also looks like completing the full proposal is not something you can do in 3 to 4 weeks before the feature freeze. If you have a look at the full proposal on the GIMP developers website, you’ll see that it should be possible to stack effects and edit their masks. It’s just that the public branch doesn’t yet have the latest work that CmykStudent demonstrated on Twitter recently: The real deal will look nothing like this. The interface you see here (the bottom part of the screenshot above) is pretty much a slight evolution of the non-destructive embryo that has already been there for many years. But most recently CmykStudent resumed his Google Summer of Code project where he hacked on non-destructive filters attached to layers. There are three major topics here to unpack.įirst of all, development of new features has been decelerating over the past few years, with focus shifted towards completing the port to GTK3. Today is the 22nd of November, the tentative release date is around May 9 of the next year, that makes nearly 5 months between now and the release and closer to 4 months between the feature freeze and the release. So if you expect to release software that doesn’t crash much and doesn’t throw too many error messages at users, at some point you have to stop writing new features and focus on fixing bugs. Every new line of code that you write has the potential to introduce a new bug or even many bugs. Right off the bat, the proposal is to start with a feature freeze in the middle of December. Below goes edited transcript of the video.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |