search

lwindolf / liferea

Liferea (Linux Feed Reader), a news reader for GTK/GNOME
https://lzone.de/liferea
GNU General Public License v2.0
804 stars 131 forks source link

GTK4 port #1325

Open nekohayo opened 7 months ago

nekohayo commented 7 months ago

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:

References:

mhoran commented 7 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 5 months ago

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 commented 1 week ago

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

lwindolf commented 1 week ago

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...