Slightly unrelated, but I wonder why the "Linux desktop maintainers" (whoever that is - and that this is even a question is probably the main problem) haven't come up yet with a minimal shared 'interface library' that's mandatory on each Linux desktop installation, and which provides a standard API (but no implementation) to create a window, get input events and probably also a set of simple UI widgets (buttons, sliders, checkboxes, lists - basically what Win32 or X11 provides).
KDE, GTK or any other concrete UI toolkit register 'drivers/plugins' with this interface library to do the actual work.
Minimal 'framework-agnostic' UI apps can then use this standard shim library and always look fully native, while applications which require the full KDE or GTK feature set can still use those frameworks directly.
Call it Common Desktop Environment or something idk...
I’m not a maintainer, but IMO, it may be the different design systems. Yes there are common elements like buttons and scrolled view. But the whole selling point of a toolkit is consistency, especially around more advanced widgets.
> But the whole selling point of a toolkit is consistency, especially around more advanced widgets.
In theory yeah, but that consistency is out the window anyway when some apps I'm using are GTK, others Qt, and yet others Electron with the JS framework flavour of the week.
A standard shim library which would map to the user's preferred framework (e.g. GTK or Qt) would at least be visually consistent between GTK and Qt - and not just for the window chrome) - even if it only offers a common subset of GTK vs Qt vs ... features.
Why don't the developer do the shim themselves? You can always have a core and shell out the UI to the platform being used. One example is Celluloid [0] (GTK) and IINA [1], both use mpv as their backend. Why not have something like libslack, libspotify (a real one), or libdiscord, then have a more appropriate frontend to meet the users where they are.
...more code in the client that should really be part of the 'operating system', and if I need to do it myself anyway, why should I care about consistency with other applications?
Such an idea only works if it is less work for application developers, not more. And I think the right place for that is the operating system layer, not the application layer.
Yes, but Linux is only the kernel, everything else is someone else project. A distribution is nothing else than a curated list of software projects.
macOS is a good example of what you're proposing. The developer toolkit have a lot of nice frameworks (libraries) to help build apps. But that ties you to Apple. You can't expect consistencies across OS unless someone does the work to provide an intermediate layer, and then you loose on each OS nicest capabilities.
It may not make business sense, but the most elegant solution is to have a core that is your feature set, and then flesh out each dependency according to the platform.
KDE, GTK or any other concrete UI toolkit register 'drivers/plugins' with this interface library to do the actual work.
Minimal 'framework-agnostic' UI apps can then use this standard shim library and always look fully native, while applications which require the full KDE or GTK feature set can still use those frameworks directly.
Call it Common Desktop Environment or something idk...