Joshua Strobl, the lead developer of Budgie, the (currently) Gtk+-based desktop, posted a lengthy article about the state of the project and the future it’s embarking on. Budgie had been in a feature-freeze and maintenance mode for a long time, but now that Strobl is no longer involved with the Linux distribution Solus, Budgie has become truly independent, and development can pick up again.
The article touches upon a lot – such as the way the Budgie developers intend to lead the project, how they want to involve the community as much as they can, and similar things. They don’t want to mandate defaults or force distributions into “stock” Budgie. They intend to take this pretty far.
We have made technical decisions for Budgie 11 and beyond that focuses on a clear separation between the “data layer” that enables complex Budgie functionality, and the visual / “presentation layer”. This reduces our reliance on any one given upstream for a toolkit or related libraries, allowing us to potentially explore different models for achieving the presentation layer, and even enabling other developers to build on top of Budgie’s data layer with their own presentations.
As for actual plans for future versions – they intend to first nip and tuck Budgie 10.x, the current version, before diving fully into Budgie 11. The idea is that they want Budgie 10.x to be a solid base for distributions to work with while Budgie 11 is being developed.
When I created Buddies of Budgie, my first priority was “unlocking” Budgie 10.x so everyone from Ubuntu Budgie to GeckoLinux, myself and other independent contributors – could get it into a state we were all happy with, and that users would be even happier with. I was not happy with the state it was in and there was a lot of catching up for us to do on fixing a thousand papercuts.
Some of the major points that need to be addressed is adding full Wayland support to Budgie, since Budgie 11 is intended to be Wayland first. They also intend to remove a whole bunch of GNOME technologies they’re currently relying on. Budgie 11, meanwhile, will be a big change.
Budgie 11 will take this much further. All data-related logic, collating, and reformatting possible will be in daemon, allowing the presentation layer (panel, applets, Raven, and more) to be much simpler. We will likely be leveraging protobuf to create more structured messages that is supported in more programming languages.. Not only that but this actually minimizes the impact that the toolkit choice will actually have and will even pave the way for other developers, should they choose, to leverage the data layer of Budgie and build their own “presentations” on top of that and in the toolkit of their choice! Budgie / its libraries / window manager will be written in a mix of Rust and C – with Rust being the choice for aspects of Budgie that are more mission critical (like the window manager, which may leverage smithay).
Budgie Desktop itself will always be designed for the “desktop” metaphor.
I’m getting mild KDE vibes from this. There’s definitely room in the market for a Gtk+ desktop that embraces more of the user choice first mentality of KDE, especially now that GNOME has forced that ship to sail.
It’s fascinating to read all of these musings, and it provides a great insight into a project trying to reinvigorate itself.
>I’m getting mild KDE vibes from this. There’s definitely room in the market for a Gtk+ desktop that embraces more of the user choice first mentality of KDE, especially now that GNOME has forced that ship to sail.
Why don’t people not just use KDE?