I'm not particularly surprised: who wants to try to hold up GIMP as an exemplar of a good interface? Maybe by arguing "it's not as bad as it was, and now it hardly sucks at all".
I'm an old Photoshop user who has GIMP now. I'd like to do a breakdown of everything that's wrong with its interface behavior, but analysing exactly how it does behave would be a major mission. There's something - several things - wrong with how it selects, moves, deselects, selects layers, and zooms, compared to what I expect for the workflow I try to have. Possibly this is just a matter of needing to learn new conventions, but possibly I have learned the GIMP conventions and they're just clunky.
Interesting, though, since this is organic, grass roots, free software interface crappiness, not the coercive corporate kind.
I have used Photoshop and GIMP a lot. I do not see how GIMP interface is that clunky.
It seems clear to me that most people get used to some interface and anything different is wrong. I saw that a lot with Windows users changing to Mac or linux interfaces. Anything 100% identical is "interface crappiness". Apple interfaces have always run circles around Microsoft's, that copied things from Apple without understanding the fundamentals or hiring proper designers.
My problem with GIMP was always that it was not as powerful for the professional, like the support for color spaces with lots of bits per channel. That looks solved now, although I had not time to test is personally.
On the other hand, you could program GIMP much easier with Script Fu (a Lisp dialect) with less restrictions, like with most open source software.
I did change from Mac to Windows shortly after the millennium, and it was fine. Window buttons were in different places, but that was trivial. Windows would minimize properly instead of the "windowshade" thing Mac had at the time (folding up into the titlebar), because Windows had a taskbar to minimize to, and that was better. I disliked the prevalence of installers (generally you could just drag an executable to another Mac and it would work) and I disliked the creepy labyrinth of user-hostile system files and system folders, which has only gotten worse. But that isn't really interface. I thought the start menu was stupid, but I could just ignore it, and I still ignore it today (Explorer all the way).
On the whole I didn't think there was much difference, apart from a general vibe of crassness on Windows, which had no clear cause. But that's switching from Classic Mac OS: you're probably talking about the new OSX BSD linuxy one. Besides, it would have been Win2K I switched to, which was one of the best iterations.
I used Linux for a while too, but that was XFCE, so again kind of samey. Mainly I remember constantly having to go through Sudo whenever I wanted it to do anything, that was the distinctive interface difference.
Color spaces, a closed book to me. I can't stand color spaces, they were always some sort of unwieldy mess of interest to other people. People who print things, maybe, I don't know. From my perspective, they caused a lot of pretentious confusion when people were trying to make images on computers for viewing on computers and for some reason didn't do the natural thing and think in three bytes of RGB.
Scripting, I hadn't even thought about, and I'll give you that one. Photoshop had a mechanism for recording actions and playing them back, and it produced a linear list of actions, with no control flow. I definitely wanted a better scripting mechanism.
A while back I was making red-cyan anaglyphs [1] for which you want to have a slider that lets you move the left and right channels relative to each other so you can put objects close to the plane of the screen/paper to minimize all sorts of problems such as Vergence-accommodation conflict.
I wrote a little tkinter program to do it because, not least, tkinter is in the Python standard library.
I found out my stereograms looked OK in tkinter but when I exported the images to the web there where ghosts. What I found out was that modern GUI frameworks do color management in the sense that they output (r,g,b) triples in the color space of your monitor, which is what you get when you take a screenshot on Windows. So if you have a wide gamut monitor you can do experiments where you have a (0, 192, 0) color in an image specified in sRGB and then find it was (16, 186, 15) in a screenshot. [3] Drove me crazy until I figured it out.
What was funny was that tkinter was so ancient that it didn't do any color correction, it just blasted out (0, 192, 0) when you asked for (0, 192, 0).
It also turns out to be a problem in printing, where the CMYK printer presents itself as having an RGB color space where the green is very saturated but never gets very bright, and sRGB green also has red in it, but if you attach the printer's color profile to an image you can force a saturated green. A lot of mobile devices are going in the Display P3 direction so you can get better results publishing files in that format.
That and a few other print projects (so easy to screw up a $150 fabric printing job) have gotten me to care a lot about color management.
Yup. Issues like that have trained me to fear and avoid anything that says "CMYK" or "gamut" or similar, not because they're beyond comprehension, but because for many use cases the whole thing is an unnecessary pantomime. And it's often silently switched on by default, waiting to screw things up for you. Blender does similar things - in order to get what you intended to be pure black produce 0x000000, and what you intended to be pure red produce 0x0000ff, you have to dig down somewhere - "post processing," I think, because they suffer from some fantasy of being Pixar - and switch something to "raw", and as I remember that isn't even the whole story and there's some other tweaks to make too, just to make black output black and red output red.
and something I found amusing was that almost all of them will only take files in sRGB format even though they actually support a gamut which covers some colors better than sRGB and other colors worse. My monitor supports Adobe RGB and covers both spaces pretty well.
I think, however, that they have more quality problems if people send files that have different color profiles so they just take sRGB.
I had some print jobs go terribly bad, turns out yellow flowers are out of gamut for my camera, for sRGB and CMYK, If you try to print something that has out of gamut colors, the printer will do something to put them into the gamut and you might not like it. I learned to turn on the gamut warning for Photoshop and bring the colors into the CMYK gamut before I print, even if I am sending in an sRGB file. It didn't bother me so much when I was printing 'cards' with my Epson ET-8550, but once I had orders come back ruined, I figured it all out.
I'm an old Photoshop user who has GIMP now. I'd like to do a breakdown of everything that's wrong with its interface behavior, but analysing exactly how it does behave would be a major mission. There's something - several things - wrong with how it selects, moves, deselects, selects layers, and zooms, compared to what I expect for the workflow I try to have. Possibly this is just a matter of needing to learn new conventions, but possibly I have learned the GIMP conventions and they're just clunky.
Interesting, though, since this is organic, grass roots, free software interface crappiness, not the coercive corporate kind.