Ubuntu should make its own Qt desktop

Ubuntu the best Linux distribution should consider moving to their own Qt desktop. A Mir compositor, Yaru and a few KDE components maybe? As a case, China has two widely used projects with Qt and KDE components. Even after Canonical had to fix problems GNOME couldn’t solve they still have too many. It feels like GTK and GNOME changes are too hard to keep up, and the cost isn’t justified as they don’t even with improve the user and developer experience. Pop!_OS could follow or join forces.
Thanks Canonical I wouldn’t be using Linux if it weren’t for you!

2 Likes

That sounds a lot like Lomiri which was originally a Canonical effort but Canonical is no longer involved. Like a lot of FOSS projects, it could use support, but I don’t expect to see Canonical re-engage.

The project isn’t dead though, it was recently demoed on Manjaro. I’m sure the folks involved would welcome some support.

3 Likes

Unity 8 (now Lomiri) was/is a Qt based desktop.

I don’t think Canonical can (or want) afford its own desktop environment. That’s why they stopped the Unity project.

If offering the classic Ubuntu desktop experience is going to be too complicated or impossible with the new version of Gnome, well… it’s much easier to change desktop environment rather than creating a new one.

I used Kubuntu for a while and it’s quite easy to reproduce something similar:
kubuntu-20-10

You don’t see the top-bar because I don’t need it :stuck_out_tongue:
…but it’s possible to set it (example).

1 Like

As painful and limited GNOME support is for multiple screens with different resolutions and fractional scales, Plasma is worse. Fractional scaling in Plasma leverages Qt ability to render in arbitrary scales, so it will always be better than anything based on GTK. But that’s it. Then you have a global (not per monitor) scaling factor, you need to restart the session for it to take effect and the shell itself doesn’t honor the scaling factor without setting an experimental environment variable that causes embarrassing bugs [1]. This will all probably be solved when Wayland becomes ready for real world use cases, but until then, for all its flaws, I would stick to GNOME, unless Canonical wants to redirect resources to fix Plasma shortcomings, which I seriously doubt.


[1] https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/139#note_167681

It looks like GNOME 40 (and GTK4) is going to be a big problem for Ubuntu 20.04. It is also going to cause issues for other desktop environments like KDE (even though it doesn’t use GTK, there might be problems with GTK4 apps due to deprecation of many APIs that are essential for various features), MATE and Budgie. Unfortunately, majority of the apps use GTK, and soon they’ll be switching from GTK3/GTK2 to GTK4. This will have side-effects like not being able to load GTK modules, such as gtk3-nocsd to remove the CSD so that CSD apps look like apps without a CSD.

Unfortunately, most (popular) apps use GTK and not many use QT. This even has implications on desktop environments that do not use GTK and use QT instead, like KDE and LXQT.

Application developers will need to be persuaded to switch to alternative toolkits like QT that are continuing to support these features that are important for desktop environments. It is possible to create QT ports of applications that are free/libre software. However, it will be hard and time-consuming to maintain these ports. Also, this only applies to free/libre software. Proprietary software will be another complicated issue.

most (popular) apps use GTK and not many use QT

Maybe “many”, not “most”, Qt has a lot of strong x-platform apps. Outside stock GNOME apps, I daily use QBitTorrent, LyX, Anki, Calibre. When I’m on MacOS I use them too. Stock Plasma apps are arguably superior and are improving at a faster rate than anything GTK. Then you have Kdenlive, VLC, Krita, Okular and many others. I would argue that current offer of Qt apps is less “toyish” and more “professional” than the equivalent offer of GTK apps, but this with a pinch of salt. Then there are browsers, LibreOffice, Electron, Flutter, etc. that use their own renderers so the matter of which toolkit they use to integrate with the platform is a bit more cosmetic and less essential. Sometimes they provide both.

1 Like

In other words, I could do my daily work in a pure Qt environment, but not in a pure GTK environment. Since GNOME is still more reliable than Plasma as a DE (some reasons I already exposed above) I would be more worried about Qt integration into a GTK environment than the other way around. And I don’t think anything should be done to persuade developers to use Qt, they are already doing it and in great measure because of its superior cross-platform abilities.

1 Like

@memeplex Both Electron and Flutter depend on GTK. This means that the numerous apps that use Electron (from VSCode and Codium, to Figma and Twitch) all depend on GTK.

The current reliance of vanilla Ubuntu on GNOME is encouraging people to create GTK apps, which is one of the reasons why the vast majority of apps use GTK.

Like I stated in my previous post, GTK4 has done a lot of harm to other desktop environments (including those that use QT). For example, modules like gtk3-nocsd can no longer be loaded in GTK4 programs. Also, GTK4 developers are being forced to adopt GMenu (the dropdown menu which appears in GNOME Shell when you right-click the application name on the top panel), which is causing major harm to the global menu/HUD of various desktop environments like KDE, Budgie, MATE, XFCE4 and Unity7.

This is very important for being able to switch to a complete QT desktop environment. Unfortunately, not much can be done about proprietary programs like the Snap Store (baked into Ubuntu, so is one of the hot-priority programs to be ported to QT) and Steam.

You are confusing the GMenu API and the ApplicationMenu, that have been deprecated down two years ago. the AppMenu was just implement via GMenu, but GMenu is a generic API to create a menu from GActions.

The current menu shown is this place is generated from GNOME-Shell, using datas from the Desktop files (for supplementary menu elements like) and stuff like open windows. GMenu only change how you generate the menu in itself, and replace using simply widgets for that.

The only depreciation that really have effects on QT desktop is modules (as it remove it mean that instead of injecting new features into GTK, they’ll have to be provided by librairies that will have to be included). For the rest, most of the “depreciation” have other way to handle the desired results, and are mostly technical stuff (replacement by generic API, unification of menu widgets, removal of some GNOME-specific API to place them in a more GNOME-specific library).

For the rest : headerbar-powered apps will keep CSD, non-headerbar apps will be able to show the system titlebar in environnement with SSD, etc. Not really many things will change with GTK4 compared to GTK3 for most users. Elementary Apps will still be Elementary and use libgranite and GNOME apps will still be GNOME and certainly use the future “libadwaita”, and traditionnal apps will keep being traditionnal (maybe with their own equivalent of libgranite/libadwaita one day ?).

Why not Yaru themed Cinnamon? :slight_smile:

You are correct about this.

Modules are not just created for the sake of adding features; they have a very important role in the creation of desktop environments and window managers. For example, gtk3-nocsd is very important to be able to (partially) replace CSD with SSD.

GTK is in no way dependent on elementaryOS apps, although the opposite is true (due to the fact that they use GTK). I’m not sure if you’re aware that GNOME 40 is a major problem for many GNOME extensions (much greater than the usual hassle of checking that everything works okay with new releases), including popular ones like dash-to-dock and dash-to-panel. Ubuntu is, for example, having issues with migrating ubuntu-dock (based on dash-to-dock). They are also having issues bringing Yaru to GNOME 40 and GTK4. This has led to Ubuntu having to stick to GNOME 3.38 (of Ubuntu 20.10) in Ubuntu 21.04.

I never said otherwise, it’s just that the dependence is small because most things they already do their own way and, in any case, these apps are alien and will always be. One needs to learn to live in an app-centric world, the pure platform-centric experience doesn’t exist outside Apple anymore. Platform integration is fine to some extent, but obsessing about it is a lost cause. Besides, Plasma can perfectly cope with GTK CSD. I don’t see the big deal here.

1 Like