GTK4: move dialogs outside GTK, make it modular
There is a big issue in current GTK architecture: dialogs (file chooser, color chooser, font chooser, print dialog etc.) are built inside GTK as part of it, desktop environment is not able to change its appearance and behavior.
GTK applications are used on Windows, Mac and Linux. On Unix-like systems GTK is the foundation of many desktops like XFCE, MATE, Cinnamon, LXDE. Currently GTK dialogs developed with GTK by GNOME developers fit only GNOME needs. In other Unix-like desktops, appearance and behavior of current GTK dialogs is strange — popovers as context menus, symbolic icons, lack of window margins, CSDs — these UI elements are preferred only in GNOME. GTK dialogs cannot be integrated better with desktop environment because they are not part of desktop but they are part of GTK itself.
I would like to propose new design of GTK dialogs architecture. Please see diagrams.
And my suggestion:
→ Remove dialogs from GTK. Current GTK dialogs classes should be changed to abstract classes or interfaces or proxies (?), without implementation.
→ Each desktop environment provides its own library with GTK dialogs implementation which follows standard defined in GTK docs. Maybe GTK should provide interface which should be implemented by classes.
→ Application calls GTK to create instance of dialog class the same way regardless of used desktop. In other words: libraries provided by desktops (see diagram: libgtkdialogs-*) should not be used directly, they are private for GTK. GTK should provide method to initialize dialogs: maybe current dialogs classes (GtkFileChooserDialogs etc.) should work as proxy between application and real dialog?
→ Move current dialogs implementation to GNOME’s libgtkdialogs-gnome.
Advantages of this architecture:
· GNOME developers don’t have to test dialogs outside GNOME like here: https://blogs.gnome.org/mclasen/2014/07/28/a-talk-in-9-images/
· GNOME can better integrate its own dialogs with desktop. For example: GNOME’s (not GTK’s) file chooser can read Nautilus settings or can use Nautilus context menu, printing dialog can use GNOME settings directly etc.
· Dirty workarounds like “gtk-dialogs-use-header” can be removed.
· Other desktops are able to provide its own dialogs to fit its own needs. XFCE has its own XfceTitltedDialog with customized title section, MATE prefers deprecated GtkColorSelectionDialog instead GtkColorChooserDialog preferred in GNOME.
— On my second picture I placed KDE dialogs for GTK. It seems to me it’s clear that it should be written in GTK, not Qt. But, for example, this architecture allows KDE to follow its own file chooser layout and integrate GTK’s version with KDE’s bookmarks and settings.
— Linux distros for begginners which work out-of-the-box (like Ubuntu, Fedora) should install package with proper libgtkdialogs-* according to preinstalled DE. OSes for advanced users (like Gentoo, Arch Linux) should provide instructions for installing proper dialogs backend in its wiki.
— I don’t think about bare GtkDialog class. It should be kept in GTK.
And my question: it is possible to do this change in GTK4? How hard is it?