Kicking Off Budgie 11: Budgie Desktop To Begin Decoupling From GNOME, Will Use Qt

jeremy · 01-25-2017, 09:56 AM

Quote:

With the Budgie website now up and running, let us turn our focus to the development of Budgie 11 itself. It’s no secret that we’ve been very busy over in Solus land, focusing on the base layers of the operating system. We did also promise we’d be kicking off the year with a focus on the next major release in the Budgie Desktop project, with version 11.

However, we’ve also thought long and hard about exactly what we want Budgie 11 to be, how it looks, and how we want to deliver the best experience to our users. It’s also no secret that for a while we’ve planned to decouple Budgie from GNOME over a series of releases.

Explaining the deGNOMEing

Originally, Budgie intended to integrate with GNOME applications. What actually happened is that it then fully integrated into the GNOME stack. We got our integration, but at a heavy cost. Over time, as GNOME has evolved, every single major release of GNOME has caused issues for Budgie. This is from 3.10, when Budgie first began, all the way through to GNOME 3.22. Whether it’s API or ABI changes, components eating other components (such as Mutter folding in cogl and clutter), many, many theme and widget breakages, GdkScreen APIs no longer functioning the same, or even segfaults caused due to the behaviour of GSettings relocatable schemas being changed.. You get the idea.

Let it be known, this post is not designed to insult or belittle GNOME. The fact of the matter is, as a project, I have tremendous respect for GNOME. They have a vision and intend to see it through. Unfortunately, this has made it difficult for a project with the complexity of Budgie to then reuse those same components of GNOME. For simpler projects, reusing parts of the GNOME stack is very trivial, as we know from our own origins. However, once you grow in complexity, have deep settings & configurability, multiple panels, a stable ABI and a proper plugin API system with support for dynamic applets that may also have per instance data, the picture quickly becomes far more complicated.

At this moment in time, the core remaining reason for Budgie even “working” on the GNOME stack, is that it expends an awful lot of effort pretending to be GNOME Shell. To give an architectural insight, consider this small example. To display device & volume notifications, the GNOME Settings Daemon sends a message to the org.gnome.Shell name on D-BUS. In our case this has to be budgie-wm, which has to pretend to be org.gnome.Shell for keyboard layouts and shortcuts to work with GNOME Settings Daemon.. Unfortunately, you cannot provide normal GTK+ widgets within the Mutter process (budgie-wm), so then we forward this notification onto the GTK+ process, budgie-daemon. The same is also true for the EndSessionDialog, and various other pieces.

It didn’t start out like this of course, but as the GNOME platform evolves, so must derived desktops to maintain the integration. As such, our roadmap for Budgie 11 set the priority of undoing this deep coupling to the GNOME stack, and moving away from Vala, to regain control over the experience, feature-set, and stability, of the Budgie Desktop.

Retrospective Q&A.

After many, many, many back and forth discussions, we asked ourselves some important questions. These would help us in turn to determine exactly what we were happy to use and work with.

...

Official Announcement...

How many LQ members are currently using Budgie? How many are considering it?

--jeremy

fido_dogstoyevsky · 01-25-2017, 02:21 PM

I'll probably have a look at the Qt version when it's available. Then it depends on the look and feel (ie how far degnoming has gone).

ChuangTzu · 01-30-2017, 02:18 PM

curious if they will base it on Unity when they move to Qt. Seems like more DE's are making this move.