GIMP 2.99.2 Released With GTK3 UI, Working Wayland Support, Other Big Changes

[verude]

I believe this is one of the things that Wayland will allow more readily via client-side decorations

I'd rather not wait for devs to implement this (if they ever actually do), with this https://github.com/Zren/material-decoration I already have it for most of my programs, and with globalmenu the titlebar disappears (and the menu goes into my top panel) when the windows are maximized, for saving even more vertical space.

[aksdb]

In principle I agree, in practice I'm really comfortable with VSCode, PS, Chrome, and other software that uses CSD in a smart way.
However I just can't stand Gnome approach, because many apps are far less user friendly than their previous versions with menu bars.
These are imho great posts about linux ui/ux
https://medium.com/@probonopd/make-i...1-5fa0fb369b42

I usually end up with problems with tools that use CSD. They are missing proper window borders and therefore their windows are not distinguishable from other background windows. Apart from the problem that it's then often hard to resize them since they pick smaller resize borders than the rest of my DE.

(I also find it easier to quickly find windows if their title bars are styled the same way. If every app looks somewhat different, it's a lot of fun spotting it between 20 other windows that all look kinda custom.)

[ssokolow]

In principle I agree, in practice I'm really comfortable with VSCode, PS, Chrome, and other software that uses CSD in a smart way.
However I just can't stand Gnome approach, because many apps are far less user friendly than their previous versions with menu bars.
These are imho great posts about linux ui/ux
https://medium.com/@probonopd/make-i...1-5fa0fb369b42

*nod* I've read those. Aside from the global menu bar, I agree whole-heartedly.

(I just can't help but value visual coherence more than that Fitts's law optimization. Put the menu bars on the windows they affect.)

...and those aren't GNOME's only "UI/UX cargo cult" evils. For example:

1. Changing away from the floppy disk icon for save when a first-year HCI textbook will tell you about research that shows that affordances (ie. metaphors like "drag a file to the trash can to delete it") only speed learning but, once everyone knows what the symbols mean, consistency is most important. (ie. Younger generations may not recognize floppy disks, but they recognize "the Save glyph".)
   
   ...also, floppy disks have other advantages, such as being easier to recognize at small sizes than overloading the green downward-pointing arrow and being shown in a cascade for "save all" or "save project".
2. Dialog action buttons go in the bottom-right corner (in western locales) because actual research showed that they should be where your eyes wind up when you finish reading it like a paper form.
3. They don't understand conceptual scoping. "Edit > Preferences..." is proof of that, because the "Edit" menu is intuitively document-scoped, and "Preferences..." is an application-scoped action.
   
   (It's like the difference between page actions and browser actions in Firefox and the original Chrome vision. You wouldn't put the hamburger button inside the address bar, would you? ...and if you put the downloads button inside the address bar, people would expect it to only show downloads for the current tab and would worry about whether closing the tab would cancel in-progress downloads.)

[Vistaus]

They should copy Photoshop and put the menu into the titlebar

And here I thought uid313 would be the first commenter to talk about things Photoshop does better, as usual, but this time *you* took the lead. Nice.

[Vistaus]

How about you swallow your silly pride and acknowledge that PS made is pretty well designed?
One could argue that copying is a fundamental part of progress, but I'll keep it simple for you: content creation software should show more of the content without sacrificing functionality.
A good way to save space, give more room to the content, and at the same time preserve access to the advanced functionality is to simply move the menu bar into the title bar.
Photoshop did that in 2010, so it's not exactly brand new.
In case you didn't notice other software have done the same, the first one the comes to my mind is visual studio code.

DominoTree I really hope so

Is PS well-designed or is it actually badly designed but people have gotten so used to it that they don't know what a good design feels like?

[JackLilhammers]

And here I thought uid313 would be the first commenter to talk about things Photoshop does better, as usual, but this time *you* took the lead. Nice.

Someone had to carry that burden.

Is PS well-designed or is it actually badly designed but people have gotten so used to it that they don't know what a good design feels like?

That's a chicken and egg question, but here you can see a little of the ui evolution over the first 20 years and make a little educated guess maybe

https://www.webdesignerdepot.com/2010/02/20-years-of-adobe-photoshop/

[JackLilhammers]

*nod* I've read those. Aside from the global menu bar, I agree whole-heartedly.

(I just can't help but value visual coherence more than that Fitts's law optimization. Put the menu bars on the windows they affect.)

...and those aren't GNOME's only "UI/UX cargo cult" evils. For example:

1. Changing away from the floppy disk icon for save when a first-year HCI textbook will tell you about research that shows that affordances (ie. metaphors like "drag a file to the trash can to delete it") only speed learning but, once everyone knows what the symbols mean, consistency is most important. (ie. Younger generations may not recognize floppy disks, but they recognize "the Save glyph".)
   
   ...also, floppy disks have other advantages, such as being easier to recognize at small sizes than overloading the green downward-pointing arrow and being shown in a cascade for "save all" or "save project".
2. Dialog action buttons go in the bottom-right corner (in western locales) because actual research showed that they should be where your eyes wind up when you finish reading it like a paper form.
3. They don't understand conceptual scoping. "Edit > Preferences..." is proof of that, because the "Edit" menu is intuitively document-scoped, and "Preferences..." is an application-scoped action.
   
   (It's like the difference between page actions and browser actions in Firefox and the original Chrome vision. You wouldn't put the hamburger button inside the address bar, would you? ...and if you put the downloads button inside the address bar, people would expect it to only show downloads for the current tab and would worry about whether closing the tab would cancel in-progress downloads.)

I've mixed feelings about the global menu. I'm not a fan, but I could live with it much more easily than with, say, Gnome's top bar.

1. I think that consistency could be reasonable overshadowed for some particular cases, like the trash bin.
   Something along the lines of
   Special cases aren't special enough to break the rules.
   Although practicality beats purity.
   from the Zen of Python
2. Amen to that!
3. Can't agree more. I always found it quite baffling!

[Guest]

*nod* I've read those. Aside from the global menu bar, I agree whole-heartedly.

(I just can't help but value visual coherence more than that Fitts's law optimization. Put the menu bars on the windows they affect.)

...and those aren't GNOME's only "UI/UX cargo cult" evils. For example:

1. Changing away from the floppy disk icon for save when a first-year HCI textbook will tell you about research that shows that affordances (ie. metaphors like "drag a file to the trash can to delete it") only speed learning but, once everyone knows what the symbols mean, consistency is most important. (ie. Younger generations may not recognize floppy disks, but they recognize "the Save glyph".)
   
   ...also, floppy disks have other advantages, such as being easier to recognize at small sizes than overloading the green downward-pointing arrow and being shown in a cascade for "save all" or "save project".
2. Dialog action buttons go in the bottom-right corner (in western locales) because actual research showed that they should be where your eyes wind up when you finish reading it like a paper form.
3. They don't understand conceptual scoping. "Edit > Preferences..." is proof of that, because the "Edit" menu is intuitively document-scoped, and "Preferences..." is an application-scoped action.
   
   (It's like the difference between page actions and browser actions in Firefox and the original Chrome vision. You wouldn't put the hamburger button inside the address bar, would you? ...and if you put the downloads button inside the address bar, people would expect it to only show downloads for the current tab and would worry about whether closing the tab would cancel in-progress downloads.)

Well regarding save, auto-save by default is a good idea. Except for some cases (say when editing fstab and other similar system config files). Otherwise, for general purposes like software development and document editing, auto-save with history is a great idea.

[Togga]

What, no Python2 support? Probably, Vala (or C) is a better choice anyway with introspection. Conversion time.

[ssokolow]

Well regarding save, auto-save by default is a good idea. Except for some cases (say when editing fstab and other similar system config files). Otherwise, for general purposes like software development and document editing, auto-save with history is a great idea.

Generally, my perspective is "auto-save with git as a way to veto it when it inevitably does something stupid" but that's not the point I was making.

It was glaringly ignorant of them and counterproductive to replace "the Save glyph" in their icon themes with iconography of internal hard drives and "download arrows" just because nobody uses floppy disks anymore.

Plus, I also neglected to mention visual acquisition. I find it much easier to look for a floppy-disk shaped... possibly in red and blue... than yet another green downward arrow. (I'm still at the stage where, lacking even green as a cue, Firefox's PDF viewer's new GNOME-ish download icon can take up to 10 seconds as I scan for the floppy several times before forcing myself to the slow path of consciously considering every icon.)

EDIT: I should clarify that I was using the Firefox icon as an example of breaking from convention. I have no problem with the standard "large down arrow pointing at a horizontal bar" download icon Chrome's PDF viewer uses. It's just Firefox's "tiny down arrow pointing into a folder" icon which is hard for me to latch onto. I called it GNOME-ish because it's inventing something new that they thought would be better, rather than matching convention to build off people's existing expectations.

It's a distinction I thought was important to make, given that GNOME botched up "save" while these things use "download", and those are two distinct pieces of iconography, even if some people are trying to conflate them. Heck, in this era of cloud apps, it's more important to distinguish than ever since, for a cloud app, "Save" usually means "Save changes to server" while "Download" usually means "Export to local machine".