Introduce support for GTK 4

[mathiascode]

As a long-term goal, support for GTK 4 should probably be introduced. GtkMenu is removed in GTK 4, which complicates this process somewhat.

[sunweaver]

@mathiascode: any idea from your side?

People suggest switching over to GtkPopoverMenu for rendering, but those are extremely awful by design.

Another option could be to rip out GtkMenu from GTK-3, provide it as a separate library, make it work with GMenu datastructures, but render it like GtkMenu.

I suppose, that desktop environments like MATE, XFCE, etc. will also be whining about the removal of GtkMenu...

@tari01: your 5 ¢ on this?

[sunweaver]

ah, for deeper reading-in...
https://discourse.gnome.org/t/using-gtkpopovermenu-as-a-gtkmenu-replacement/3786/4

[tari01]

We are entirely built around GtkMenuItem. ayatana-ido expands on that, libayatana-indicator hacks the rendering for it. I say we wait until the GTK people make a final decision on how they want this whole action <-> menu to work in the future...

Edit: I cannot imagine a functioning desktop environment without decent standard menus. I'm still hoping the GtkMenu will survive somehow. GTK cannot seriously expect MATE, XFCE, etc to completely rewrite their environment.

[mathiascode]

I doubt GtkMenu will ever be considered again upstream. After some trial and error, I've spent a considerable amount of time porting Nicotine+'s menus from GtkMenu to GMenu + Gtk.Menu.new_from_model or Gtk.PopoverMenu.new_from_model_full, depending on the GTK version.

In GTK 4, GtkPopoverMenu has a new GTK_POPOVER_MENU_NESTED flag, which essentially restores the behavior of GtkMenu submenus. GtkPopover has a new set_has_arrow() function that removes the popover arrow.

The resulting code is here: https://github.com/Nicotine-Plus/nicotine-plus/blob/master/pynicotine/gtkgui/widgets/popupmenu.py

Some screenshots for clarity:
GTK 3:

GTK 4:

For plain menus, GtkPopoverMenu is certainly an improvement over its GTK 3 counterpart, but you're probably out of luck if you need direct access to menu item rendering.

[tari01]

@mathiascode Thanks for sharing this. Once we've eliminated all the bugs and PRs from the entire Ayatana ecosystem, We'll do some major (re)coding :)

[DeedleFake]

Any updates on this? I recently ported my app's UI to Gtk4/Libadwaita and it looks great but I can't get a tray icon no matter what I try, as pretty much every single library for it seems to depend on Gtk3, and you can't link both versions simultaneously.

[hwittenborn]

It's really hacky, but the method I'm using in my application (you can find it here for reference) is creating my main GTK4 application, and then making my app's tray icon a separate app in GTK3. The two then communicate via DBus, and it works pretty much fine as long as you add in some error handling for when either side dies out. It's definitely a bit on the hacky side, but if you want an immediate solution I've found it to be quite effective.

I heard somewhere a while back that some application got something working in pure GTK4 to work with system trays, I forget where I saw it though.

[yochananmarqos]

@hwittenborn

I forget where I saw it though.

😉 👇

hwittenborn/celeste#25 (comment)

[hwittenborn]

Crud I don't know how I forgot about that, lol. That'd definitely be where though. I'm gonna have to look into what they do to see if I can find any clues.

[DeedleFake]

Any updates on this? I recently ported my app's UI to Gtk4/Libadwaita and it looks great but I can't get a tray icon no matter what I try, as pretty much every single library for it seems to depend on Gtk3, and you can't link both versions simultaneously.

Follow up: I recently tried the Fyne project's system tray implementation again again and it worked fine for my purposes. They've removed the Gtk3 dependency and it's now pure Go on Linux via a native D-Bus implementation. It's not perfect, especially as the D-Bus implementation is very inefficient and performs far more allocations than it probably should, but it works.

[mathiascode]

Crud I don't know how I forgot about that, lol. That'd definitely be where though. I'm gonna have to look into what they do to see if I can find any clues.

It's a partial implementation of the StatusNotifierItem spec for our needs, communicating with the org.kde.StatusNotifierItem and com.canonical.dbusmenu D-Bus interfaces, and replacing libappindicator/libayatana-appindicator and libdbusmenu. A notable omission is submenu support, since we don't use them in Nicotine+.

The better long-term option would be to either replace libdbusmenu-gtk in libayatana-appindicator, or update it to use something else than GtkMenu. However, 1. it's a fair amount of work across the entire project if done properly (AyatanaIndicators/ayatana-ido#51), and 2. I'm personally not too fond of using the AppIndicator implementation due to past design decisions, such as omitting support for primary click actions.