#Development

#Budgie Control Center

This week, we included an Introduction panel into the existing 10-series Budgie Control Center. This section provides a distribution-configurable panel with access to various quick settings and additional settings utilities. Since display configuration moved out of Budgie Control Center for Budgie 10.10, ensuring users have a clear and approachable way of launching display settings from the same Settings app they are familiar with is important. Internally, the team discussed how that would end up working in practice (for example, whether the old "Displays" panel would just have a button to launch wdisplays), however in the end David came up with this more flexible solution. By default, this section will have a Quick Start to go to panels for Power, Sound, Wi-Fi, and Networking. For additional settings, we provide an easy way of firing up wdisplays (as that is the preferred graphical display configurator for Budgie 10.10) and Budgie Desktop Settings. Once this is landed in a Budgie Control Center release, it'll ship in Fedora with an "Additional Settings" item for launching Bluejay for Bluetooth management.

#Budgie Desktop Services

A couple of patch releases of Budgie Desktop Services were released this week.

• 1.0.1: This release fixed propagating some of our "MetaHead" (sits in front of a wlr head) properties such as AdaptiveSync and Scale to the persistent configuration.
• 1.0.2: This turned off installation of a custom labwc autostart file by default, as we had since implemented a solution for launching the service via our launch script in budgie-desktop. We are going to continue to monitor how Services behaves during compositor restarts / crashes, rather than rely on compositor-specific hooks, and make sure to address any issues that arise related to use of the wayland socket should any occur.

#Budgie Desktop (10.10)

A couple notable items have landed in budgie-desktop since its release last week:

1. Support for setting different modes for swaybg
2. Fixes for launching Budgie Desktop when using greetd

For the first, Budgie 10.10 shipped with swaybg calls set to fill to avoid backgrounds getting skewed if they have a different aspect ratio than the respective output (display). Now, we will check the preferred placement mode / "style" defined from GnomeBG, mapping various "styles" to swaybg modes. We have made this configurable via the Background panel of Budgie Control Center. Regarding the second item, greetd does not start Budgie Desktop from the desktop file, which leads it to set a dummy XDG_CURRENT_DESKTOP. At launch, we will now check if XDG_CURRENT_DESKTOP doesn't contain Budgie and force the value if it is missing. These updates will land in a minor 10.10.1 release. However, given how new Budgie 10.10 is, we will let it cook a bit to provide time for feedback and address any issues before we tag another release!

Something else that David (fossfreedom) has been cooking up is support for Wayfire, including a bridge for settings (similar to what has been done for labwc). It is still experimental, but figured it was worth a share even just to show another compositor running Budgie Desktop already. If you care to go back over a decade to the world of wobbly windows and funky app switchers, this will be right up your alley!

#Budgie Desktop View

While Budgie Desktop View does not yet support arbitrary positioning of contents of your Desktop folder (that'll come when we port it to Qt6), support has just landed for being able to manually sort entries on the current Flowbox, as an alternative to the alphabetical sorting. You can expect this to land in next minor release of Budgie Desktop View.

#Website

The Buddies of Budgie website has now moved off GitHub. Previously, our Vercel deployment flow leveraged the Vercel GitHub app, however with the move we are now using Vercel's deployment tooling via its CLI through a Woodpecker CI workflow. One less repo on GitHub! Alongside this, I have spent time this week updating the site (locally) to finally using Nextjs's App Router and moving it from using MUI to Tailwind CSS + shadcn/ui. This will lay the groundwork for a subsequent redesign planned as part of an effort to better communicate: current Budgie, future Budgie (11), the organization, development, and more. Hopefully will get that groundwork rolled out by next weekend :)

#Budgie 11

This week as part of our planning phase for Budgie 11, we have come to the following decisions related to what libraries we want to use, internal plumbing, and bootstrapping a couple Budgie 11 repositories.

#Configuration

For context, we currently leverage toml11 for serialization and deserializing of our display configuration in Budgie Desktop Services. While the library is great and the TOML format is preferred for "user-facing" files, the current implementation results in a few pain-points:

1. It requires a fair bit of code to translate between internal Qt and standard C++ types.
2. If we wanted to expand the places we monitor for this file, we would have to cook up our own file monitor (not the worst thing using QFileSystemWatcher to be fair).
3. We would need to handle format migrations manually. There was already a format change early on during development (then the subsequent "shim" format), it is reasonable to assume there will be more in the future.

As we expect to use similar configuration for the panel, notifications, and shell, it makes sense to adopt an existing solution that addresses these pain points (and submit improvements down the line if we find any opportunities to do so). Consequently, we have decided to adopt KConfig. This move provides several key solutions:

1. It is schema-first, utilizing codegen to handle generating code for reading and writing the respective schema.
2. It facilitates migrations and supports layered or cascading configurations, which is ideal for overlaying user settings onto vendor or distribution defaults.
3. By leveraging KConfigWatcher, our goal is to enable configuration-driven panel changes.

The last one is most notable as we only want to build out services (exposed over RPC) when actually necessary. We plan on first exploring panel management and configuration by having each panel be a watcher for its own panel config, with a control center settings area / panel being used to manipulate the configs (whenever we delete or add a new config, the shell would then spin up the panel and configuration loading is handed off to the panel). This should address one of the key issues we faced with Budgie 10.10 where Budgie Desktop Settings was deeply coupled with the panel manager. While the user-facing format ends up being more INI than TOML, it is still completely approachable, and worst case in the future we can always write some code and submit a proposal for TOML support! I expect that the first place we will start testing KConfig integration is with our compositor (more details on that below), followed by our shell, then proceeding to add support to Budgie Desktop Services (ensuring the TOML config gets translated over, then no longer written to).

#Panels and Raven

In Budgie 10.10, Raven is architected as a completely separate window that consumes one side of an output. Although the panels already handle their own GtkLayerShell calls and window state, Raven was not originally conceived as a panel. This conceptual separation prevented shared code reuse, requiring Raven to maintain its own independent implementation. This is being rectified in Budgie 11 by ensuring Raven sub-classes the Panel (or a similar shared class between the two). This architectural shift provides several key advantages:

1. By redefining Raven as a specialized panel, we can share the core code responsible for layer-shell interaction. As we iterate on the panel, those architectural improvements will immediately benefit Raven.
2. We will be able to perform overrides for specific Raven behavior while ensuring it has predictable interaction and positioning across various display and shell configurations.
3. More consistent lifecycling.

#budgie-shell repo

We have established the budgie-shell repository to serve as the central hub for core shell components. At this stage of development, we have agreed that the repository will manage the following responsibilities:

• On-screen displays (OSDs)
• Notifications (we are still evaluating how notifications will integrate with Raven to avoid specific pain points related to the notification server)
• Panels

In a departure from previous versions, Extensions (the new Budgie 11 terminology combining applets and widgets) will each maintain their own source repository rather than living within budgie-shell. This change should enable us to iterate on and version extensions more easily. Furthermore, this decoupled approach provides a testing ground for the centralized extension management and discovery features we plan to implement!

Thus far, the budgie-shell repository has been bootstrapped with some expected dependencies, scaffolding, and basic code to start experimenting with a panel implementation leveraging LayerShellQt.

#magpie repo

We have also initiated a new repository for magpie. This iteration will be using Mir / miral. The Mir team has done a fantastic job at documenting the project and providing clear on-ramps for developers, enabling a clearer pathway to building compositors. Most importantly for our needs, Mir provides a native C++ API that aligns well with our development goals for Budgie 11. So expect some actual code (and screenshots) to be shared in the coming weeks!

---

That covers everything for this first Chirp. We have a lot of work ahead of us, but it feels great to finally have the foundations for Budgie 11 taking shape while we keep the 10-series polished. Thanks for following along, and we will see you in the next one!