For what i heard, a lot of people on the Linux community use Krita for image manipulation, even though, it’s intended for digital painting, and GIMP is the one intended for image manipulation, because people don’t like the GIMP’s UI.
My issue is, i never understood why they don’t like the GIMP’s UI, since i never have issues with it,(Although it’s probably because i’m used to the UI) so i need to adress this problem and ask you What does the GIMP UI has that you don’t like or hate so much and why you like Krita’s UI over GIMP’s?
Before you event comment your answer i need to ask you to do the following:
-
Address each specific issue along with an concise and direct explanation of why you don’t like it
-
Answers such as “I just don’t like it”, “I don’t like where it’s placed” or anything alike doesn’t count as “Concise and Direct”, we are adults, not 4 year old children.
-
If you can provide a suggestion of how GIMP’s UI can be improved, it would help a lot, and maybe this issue can be solved.
-
If someone else commented something you were about to comment, upvote them, this way we can address the most common issues effectively.
-
I need you to watch the screenshots of both UI’s, because something that most people don’t know, it’s how similar Krita and GIMP’s UIs are.
Krita’s UI
GIMP’s UI
(Credits to a friend of mine for lettig me use the screenshots.)
My ideas on how GIMP can improve it’s UI
-
Adding the option of the new UI selected by default, but with the possibility to switch to the new UI.
-
Possibly addding “work spaces” like Krita would help too, along with the possibility of exporting and importing them, this way people can have custom arrangements of the UI according to the kind of work they will do.
Thanks for reading and hopefully we can address this issue effectively.
Because the underlying dependencies of GIMP changed a lot, especially between GTK2 and GTK3. It pulls resources from writing code to figuring out how to migrate code to a new version, usually as changes in the toolkit mean you may have to rewrite stuff anyway, which can mean more bugs or regressions in functionality which must be addressed.
Writing from scratch, you can write code that immediately fulfills the spec you’re working to (They could’ve even skipped straight to GTK4!) and used the old code as a reference of what’s needed for users whilst throwing out anything and everything else that isn’t strictly necessary.
It allows you to throw out old features and code that you had to work with in the past, but may not actually be used by anyone. If it WAS needed, it can be added later.
Most importantly, there’s little to no expectation that the new app will supersede the old one immediately, whereas during a toolkit migration you need to keep everything working for every release you do.
It’s like how building a new house can be faster than renovating an old historically-protected building to the same regulatory standard. There’s red tape, you have to work around old masonry and brickwork, you have to avoid damaging the building and keep its appearance the same. A new house may be different in looks and miss the old charm or familiarity, but it’ll be built faster, cheaper, and for the same price have more features to the old building.
I see ! couldn’t development be done in a separate branch with no expectation of an immediate release ?