Remove GTK+ in favour of UXP

[Schimon]

GTK+ is too heavy, and is subjected to too many API changes.

Looking back at those 20 years for me the GNOME ecosystem developed in a way that the maintenance work was ever increasing. The different aspects of this are the major GTK releases causing massive refactorings, continuous API deprecations causing compiler noise and work that does not benefit the features. So every time I was close to dropping the project, the reason always was the GTK development cycle. I’m not judging here, there is just a mismatch of the innovation cycle in the GNOME world and in this feed reader project. This is for example different with another important library for Liferea: libxml2. The API was practically 95% stable for 20 years. Zero maintenance effort!

https://lzone.de/liferea/blog/20-years- ... the-future

In addition. GTK+ now has on support for X11 (Xorg).

https://gitlab.gnome.org/GNOME/gtk/-/me ... uests/8060

Of course, there is GNUIsance – GTK New User Interfaces, but I do not think that GTK+ would be of any good.

https://madmurphy.github.io/libgnuisance/

Using only UXP (XBL, XUL, and XPCOM) would benefit to Basilisk, Pale Moon, and other UXP software, in the long term.

In addition, doing so would increase the attention of maintainers of Linux distributions to handle UXP as a library, not unlike any othre library available to a Linux package repository; and it would subsequently urge people to consider UXP as a graphical toolkit instead of FLTK, GTK+, Qt, Tkinter, etc., because it then would be more accessible.

I suppose, that conesquently ChatZilla would be available as a Linux package, which would further encourage the deployment of UXP.

[Moonchild]

I think you misunderstand how this works.
GTK+ is a widget toolkit. XUL/XBL/etc. sits on top of that; you can't expect us to remove the toolkit abstraction layer and start implementing the much broader variety of system libs GTK+ itself uses. If we did that, then UXP would become much heavier in itself. Also, we would lose any abstraction advantage of various widget toolkits on the operating systems we support. We already have to cater specifically to different APIs of various widget styles to be able to talk to the underlying OS.

Unless, of course, you actually want us to go the minimalist, flat Firefox route and make the UI into an HTML document that doesn't integrate at all with the OS...

[Schimon]

If feasible, then I do suggest to extend UXP as a cross-platform toolkit for the creation of graphical interfaces.

[Moonchild]

If feasible, then I do suggest to extend UXP as a cross-platform toolkit for the creation of graphical interfaces.

It already is.
XUL is a UI language allowing you to generate cross-platform applications with a consistent UI.
But you have to understand that that is one layer, that necessarily builds upon other layers (GTK+/WinAPI(DX)/CG/etc.). you can't remove the underlying layers and expect UXP to take on that task.