GTK4 port

[nekohayo]

I know this is a big architectural wishlist item, but someone's gotta file it :)

It would be desireable for sustainability, but also particularly for performance + tons of issues fixed, Liferea will certainly have to port to GTK4 someday.

This would provide:

• GPU-accelerated everything, and therefore much better performance overall
• Optional opportunities:
  • Ability (later, when time allows) to get rid of old super annoyingly unscalable and buggy widgets like GtkTreeView, and replace them by GtkListView. The new widget had quite a rough patch when it started being deployed in apps in the winter of 2023, but nowadays with the latest versions of GTK it's pretty stable and usable. Probably by the time Liferea does its GTK4 port, ListView would be very solid and a net improvement over TreeView; but Liferea doesn't have to port to ListView immediately as part of the GTK4 port (if you are ready to accept a temporary accessibility regression, see comment below); while TreeView is marked as "deprecated" as of 4.10, it still exists…
  • Ability to use libadwaita if you want it (for styling, and automatic dark theme support)
  • Ability to more easily do adaptive layouts, animations, etc.
• As a result of the codebase modernization, it would provide the opportunity to profile performance with Sysprof; I have been refraining from doing this so far because it kinda makes no sense to profile a GTK3-based application that will have to go significant overhaul to port to GTK4 someday anyway.
• It might potentially provide protection against ponies: #1156

References:

• https://docs.gtk.org/gtk4/migrating-3to4.html
• https://docs.gtk.org/gtk4/
• https://gitlab.gnome.org/GNOME/Initiatives/-/issues/26

[mhoran]

One area where GTK4 leaves a lot to be desired is managing virtual desktops. When I fixed a few bugs around the tray icon and virtual desktops, many of the functions were marked as deprecated and not implemented in GTK4. GTK4 presumes the window manager is in complete charge of virtual desktops and does not let applications get in the way. This will re-introduce frustrations when using the tray icon.

[nE0sIghT]

This will re-introduce frustrations when using the tray icon

Since Liferea supports AppIndicator we don't rely on GTK's TrayIcon implementation now which was deprecated for a long time before removal from GTK 4.

[mhoran]

Since Liferea supports AppIndicator we don't rely on GTK's TrayIcon implementation now which was deprecated for a long time before removal from GTK 4.

The issue is not with the tray implementation but with virtual desktop handling in Wayland.

https://github.com/lwindolf/liferea/blob/2f9c7ef3ede187095cd349154b654a14959709ec/src/ui/liferea_shell.c#L1498-L1544

[mhoran]

Another issue is with save / restore of window position (referenced in the code above.) IIRC, window position can no longer be set through GTK4, and is presumed to be handled entirely by the window manager.

[nekohayo]

Since Liferea is a single-window application, not a multi-floating-windows app, I think the impact of not restoring the window position on app launch/startup (unless you use the future Wayland session restore protocol) would be somewhat limited (and personally I don't really mind the window manager putting it wherever it finds free space on my primary monitor). Additionally, if you use some sort of appindicator minimize-to-tray behavior, I would expect the app to do a hide and show function call onto the window, which presumably would not be affected by window positioning issues, as it would just remain in place while hidden, and reappear in place when un-hidden.

Overall, the notion of tray icon seems obsolete to me compared to the notion of "app running in the background" through the relevant sandboxed FreeDesktop API documented here. Since GNOME 44, that DE exposes background apps in the UI, which is essentially the replacement for the Windows 95 "tray icons". Other DEs could plug into that API and expose that UI as well (I wouldn't be surprised if that was already the case, or is the case by the time Liferea does a GTK4 port).

[mhoran]

Additionally, if you use some sort of appindicator minimize-to-tray behavior, I would expect the app to do a hide and show function call onto the window, which presumably would not be affected by window positioning issues, as it would just remain in place while hidden, and reappear in place when un-hidden.

You'd expect that, but unfortunately that's not how it works (hence the code I linked to above.) I looked into this extensively, as there was a bug that caused Liferea to slowly walk its way down the screen when shown / hidden from the tray. Maybe a GTK4 migration with Wayland only would handle this better, but with the mix of all the window managers on the market that people use, plus odd behaviors, I'm not confident about this just working.

Since GNOME 44, that DE exposes background apps in the UI, which is essentially the replacement for the Windows 95 "tray icons". Other DEs could plug into that API and expose that UI as well (I wouldn't be surprised if that was already the case, or is the case by the time Liferea does a GTK4 port).

I recall that GNOME's answer to deprecation of tray icons was "use notifications". This is exactly what I don't want. I don't like notifications, but I do like having something I can glance at to see if I have any updated feeds. I don't run GNOME so I'm not sure what this looks like in GNOME 44 and if the situation has changed.

Regarding "other DEs" adopting GNOME technologies, I don't want to get into a flame war regarding desktop environments, but many of the DEs on the market today were released to address frustrations that users had with the decisions made by the GNOME project. There may be some friction here.

Regardless, a GTK4 port will have to happen at some point, though I suspect it won't be completely necessary for some time (there are still even GTK2 apps.) I just wanted to raise the above as one potential pitfall in a port.

[nekohayo]

Additional piece of information from https://gitlab.gnome.org/GNOME/Initiatives/-/issues/49 (and discussions I've had): in GTK4, TreeView is not really accessibility-friendly (less so than in GTK3, but even there it wasn't great to begin with), as there were too little resources to port the (deprecated) TreeView to the new accessibility API (it would have been a massive amount of work for arguably little benefit). With GTK4's TreeView, accessibility toolkits either get a data dump or you get only one row of disjoint cells at a time.

All in all, the idea is that the recommended way forward is to port from TreeView to newer list widgets.

[lwindolf]

As a small step I've fixed all Webkit deprecations in b0b1d89647631d06cdc0908cd20274fed8a963b1

[lwindolf]

Another small step: all use of GtkStyleContext (theme color handling) has been dropped eb0ce6356df5874726563da347b1d828bc258e08. This will need additional work to make the item view work without table backgrounds. Currently I prefer going the NetNewsWire layout style...

[lwindolf]

Some webkit deprecations have been solved