[Effects/Adjustments] Show effect icons on the menu

[pedropaulosuzuki]

Description
Following the work of #2092, we should be able to use custom widgets to show the adjustment and effect icons in the menu, using the new redesign started by @yioannides in #2091. This would help a lot on the discoverability of effects, since new users currently need to test them one by one to understand what they do, and the icons help on recognition. Suggestions like #705 probably come from this lack of icons.

However, this wouldn't just work like the ToolBarDropDownButton, because we don't have a selection and we need to run an action, no matter if we "changed from the last selection or not", so we would need another custom widget for that dropdown, unless we can magically insert the icons in a MenuButton (or similar). Otherwise we can hack on top of Gtk.Dropdown and do some magic where we ignore the selection and run an action on click/activate of a child widget, but I'd rather avoid such hacks, if possible.

Opening this for discussion on what the best method to do this would be to accomplish this.

[cameronwhite]

I'd be very strongly against any hacks like using Gtk.Dropdown for this - we can't be replacing normal GTK menus with a weird nonstandard widget. If it's not possible with GTK menus then we simply don't do it.

A couple interesting things I found while looking into this:

• https://docs.gtk.org/gtk4/class.PopoverMenu.html#menu-models mentions icon and verb-icon properties. It'd be worth looking into those for GMenuItem and see what they actually do
• More interesting was https://docs.gtk.org/gtk4/flags.PopoverMenuFlags.html which I think we should probably be setting for any menu buttons that have nested menus to avoid the annoying sliding behaviour?

For #705, I interpreted it more as avoiding the nested menus for accessing effects by having some sort of "palette" widget for quick access

[pedropaulosuzuki]

A couple interesting things I found while looking into this:

* https://docs.gtk.org/gtk4/class.PopoverMenu.html#menu-models mentions `icon` and `verb-icon` properties. It'd be worth looking into those for GMenuItem and see what they actually do

It seems they do absolute nothing... I did this quick patch (which uses the fact that Gtk.MenuButton implements Gtk.PopoverMenu automatically when provided a GMenuModel), and there were no icons.

diff --git a/Pinta.Core/Actions/Command.cs b/Pinta.Core/Actions/Command.cs
index 31561111..dcde3ebb 100644
--- a/Pinta.Core/Actions/Command.cs
+++ b/Pinta.Core/Actions/Command.cs
@@ -81,8 +81,13 @@ public class Command
 			: [.. shortcuts];
 	}
 
-	public Gio.MenuItem CreateMenuItem ()
-		=> Gio.MenuItem.New (Label, FullName);
+	public Gio.MenuItem CreateMenuItem () {
+		Gio.MenuItem item = Gio.MenuItem.New (Label, FullName);
+		if(IconName != null) {
+			item.SetIcon (Gio.ThemedIcon.New (IconName));
+		}
+		return item;
+	}
 }
 
 public sealed class ToggleCommand : Command

From this discussion, it seems the "default API" is strongly against icons in menus, for some uncomprehensible reason, which might explain why changing those properties seem to do nothing.

It seems we could possibly create the popover manually, but that would require "creating the widgets ourselves and handling activation of the actions ourselves too", which is doable. We probably would have to implement the submenus too, which now can become a real headache, as we want to implement this exactly for the Effects menu...

For #705, I interpreted it more as avoiding the nested menus for accessing effects by having some sort of "palette" widget for quick access

Yeah, probably. But I believe not having the icons might have also impacted the reporter in a negative way.

I'd be very strongly against any hacks like using Gtk.Dropdown for this - we can't be replacing normal GTK menus with a weird nonstandard widget. If it's not possible with GTK menus then we simply don't do it.

I believe having better UX is better than just "respecting GTK's wishes", because sometimes GTK's wishes are detrimental for the user experience (like in this case, not having the icons). I don't like hacks either, but I dislike the icons not being shown more. Well, at least, since we can use the Gtk.MenuButton popover, we are free from having to hack Gtk.Dropdown, at least.

[yioannides]

I believe having better UX is better than just "respecting GTK's wishes", because sometimes GTK's wishes are detrimental for the user experience

I'm a bit on the fence with this one. I share Cameron's opinion for sticking with what GTK already provides, cause it's not so much about respecting GTK's wishes, as it is about avoiding future technical debt from creating custom GTK widgets or hacks that only a handful of people hold the keys to and add extra layers of complexity and dependency when porting to future GTK iterations (see Evolution, Inkscape etc) ... on the other hand, icons exist for a reason and would be nice to see them being utilized more.

The truth is GTK's range is very limited and hasn't caught up with large-scale projects like an audio / video / graphics editor, so one has to either:

• only work within the confines of the toolkit
• do what you have to do and go all in with GTK hacks, as risky as it is
• diligently create new libadwaita-esque & purpose-based widgets and push them upstream (big community W, obviously)

TL;DR I root for both teams, go sports ⚽️ 🏀 🎾

[pedropaulosuzuki]

I believe having better UX is better than just "respecting GTK's wishes", because sometimes GTK's wishes are detrimental for the user experience

I'm a bit on the fence with this one. I share Cameron's opinion for sticking with what GTK already provides, cause it's not so much about respecting GTK's wishes, as it is about avoiding future technical debt from creating custom GTK widgets or hacks that only a handful of people hold the keys to and add extra layers of complexity and dependency when porting to future GTK iterations (see Evolution, Inkscape etc) ... on the other hand, icons exist for a reason and would be nice to see them being utilized more.

I agree complexity can generate technical debt, but lack of icons causes user experience debt, which is worse.

The truth is GTK's range is very limited and hasn't caught up with large-scale projects like an audio / video / graphics editor, so one has to either:

* only work within the confines of the toolkit

* do what you have to do and go all in with GTK hacks, as risky as it is

* diligently create new libadwaita-esque & purpose-based widgets and push them upstream (big community W, obviously)

TL;DR I root for both teams, go sports ⚽️ 🏀 🎾

Maybe if all Gtk image editors have to hack custom widgets because "Gtk says no", then maybe we really should, as you pointed out, think about a "LibAdwaita" of Gtk Image Editors, which would have all the common widgets image editors and other complex programs (as you pointed out) could use. "Only working within the confines of the toolkit without custom widgets" is not a good option when the default widgets remove the things we need.

I totally get not recommending icons on menus for small, simple programs, but that's just not good for big, complex programs like Inkscape and GIMP, and is also negatively affecting us in this case. I also strongly doubt upstream Gtk would accept those widgets, as they are the ones blocking icons on menus anyway, which is something that was available and supported, but that got removed. If I'm not misremembering, when the Audacity team decided to port from WxWidgets, they chose Qt over Gtk exactly because of the lack of icons on menus.

[yioannides]

maybe we really should, as you pointed out, think about a "LibAdwaita" of Gtk Image Editors, which would have all the common widgets image editors and other complex programs (as you pointed out) could use

I'm more of that opinion, but with the condition the developer provides good and responsible documentation to make it easy for future contributors to adopt, regardless of whether it's eventually picked up by upstream or not (most likely not, very few things have ever made it past the GNOME design team)

My dream is to have a libadwaita-based creative app suite, namely a raster & vector editor, an audio editor (DAW) and a video editor. I mostly do UI/UX prototyping so my input isn't all that actionable, but everything I design or suggest is built on futureproofing, longevity and hopefully interoperability between apps of the same hypothetical creative ecosystem, so of course custom widgets would be an advantage for such a goal, as long as it doesn't create bloat to all you main developers and committers.

when the Audacity team decided to port from WxWidgets, they chose Qt over Gtk exactly because of the lack of icons on menus

That's the quintessential FOSS editor pipeline: start development in GTK > need something GTK doesn't provide > make custom widget > widgets break with future updates > overhaul app's framework to Qt (not a huge fan of Qt, but I cannot deny the appeal it has for developers)

[cameronwhite]

One other thing to keep in mind is that this very likely could only work for the popover menus. I doubt there's any way to get the traditional menubar layout to have icons, especially since the menu might move into the native global menu bar on KDE, macOS, etc . I suspect that's partly why GTK was moving away from this too

The maintenance cost is my biggest concern though, having gone through porting Pinta from GTK 2 -> 3 -> 4. Things like custom widgets, code that relies on assumptions about GTK's behaviour, etc add a lot more work down the road.

[pedropaulosuzuki]

One other thing to keep in mind is that this very likely could only work for the popover menus. I doubt there's any way to get the traditional menubar layout to have icons, especially since the menu might move into the native global menu bar on KDE, macOS, etc. I suspect that's partly why GTK was moving away from this too

Yeah, the traditional menubar is more of a fallback anyway, while we don't solve the underlying issues with the current MenuButton approach, that being some items hidden deep in the hamburger menu (#1428) and the opening of a MenuButton not being persistent (meaning you clicking to open one and hovering over another not switching to the other menu). If those are fixed, then the menubar will only be used for KDE/Unity global menus.

The maintenance cost is my biggest concern though, having gone through porting Pinta from GTK 2 -> 3 -> 4. Things like custom widgets, code that relies on assumptions about GTK's behaviour, etc add a lot more work down the road.

Yeah, unfortunately that's the cost of Gtk willingfully removing features application developers need for "reasons".