Serious question: I’ve been using Krita to mess around with the tablet, but are there any good reasons to learn GIMP coming from a photoshop background all these years, given that I also know Krita somewhat?
So glad they’re moving forward on the non destructive front! Non destructive editing such a useful feature. I will always prefer to be able to non-destructively edit things I’m working on to easily be able to change things if necessary or to be able to see how I did something in the future!
This is controversial but will I be able to map right click to erase or another tool/brush preset/color? It just feels wrong to keep switchimg with N and Shift+E while making pixel art.
I don’t need any of the advanced tools, I just want a cleaner interface for the tools that already exist. The only thing I’m able to do is make header pics for my posts. The 2.x UI is really, really old now. The time for a refresh was a few years back, but I do understand the limitations of a small team. Like others have said, I’ll likely run both and migrate to 3.x when it’s stable. Though, I do like the idea of non-destructive editing :)
Krita has been adding photo manipulation tools faster than GIMP is fixing their UX/UI, so at this point I think Krita will be the first to become the most viable FOSS alternative to Photoshop.
I would NOT say it has been on decline. It's pretty good for its target. There also hasn't been any regressions I can see except for the obvious Nautilus. (I use MATE, but mostly because of its looks)
I realize that the major point of GIMP 3 is the port to GTK3. That said, I feel like colour spaces are what people have been waiting for and probably the most significant deficiency that keeps GIMP from being treated as a professional tool.
If they are really this close, why not set the GIMP 3 release date for when colour management is ready?
Non-destructive editing will be huge as well. GIMP 3 is really going to be a crazy leap forward. It is going to be amazing to finally get access to all this work that has been walled off for decades.
The bug situation sounds terrible. Honestly though, they should just get 3 out and then make bug fixing the number one job until it gets into better shape.
Not only is it a small team but right now there are basically two different projects ( 2 and 3 ). With only one code base, perhaps the pace of progress can improve.
So you're saying: don't release the GTK 3 port until colour spaces are also complete? Why not give people what's ready, and then when colour spaces are ready, cut another release? No need to make people wait who don't need colour spaces.
(Additionally, it's easier to verify that bugs reported before the release of colour spaces are more likely to be related to the GTK3 port.)
Colour spaces are ready. They are saying I may be hard to wire it up in all the right places in a month. Why not take two months and get it in? I mean, it has been over a decade already.
Many people have been waiting for 3.x for literally half their lives. To save a month, they are going to launch 3.x with the big change being the toolkit? Seems like a wasted opportunity.
If it were going to be 6 months or more I would agree with you. From the write-up though, they delay would only be a few weeks.
The GTK3 port has been in the making for a very long time. Long before anyone even mentioned GTK4. Porting an application to a different GUI toolkit is a lot of work.
And it shouldn’t be. Sure, there are some new features you may want to take advantage of, but it’s lamentable that GTK doesn’t try harder to maintain backwards compatability.
You know who does major version changes well? Go. Excellent backwards compatible over a decade of very active development, and when there are recommended or required changes, the compiler provides tooling to update source code to the new API.
GTK2->GTK3 was a major leap. For something like a GUI toolkit, changes and advancements are inevitable. A GTK4 port would be much less difficult, as the developer-facing changes are an order of magnitude smaller.
Yes, it shouldn’t. Unfortunately, the developers of GTK thrived on changes to the API during the GTK3 era. I don’t know why Go devs don’t (and I am indeed very glad that they don’t). Perhaps it’s because of the different structures of the development teams or perhaps because GTK has more hazy goals. 🤷♂️
According to the GTK team, trying to maintain backwards compatibility dragged the whole project down. I agree that a basics' automatic porting tool would've been nice.
Add comment