Extending Budgie Desktop Settings to include GNOME Settings

[fossfreedom]

From here https://gitlab.gnome.org/GNOME/gnome-control-center/-/blob/master/meson.build#L105

GNOME Settings from GNOME 42 will have the libadwaita dependency. What I don't know is if it has the ability for distros to bundle a separate stylesheet/file to allow colours to be changed. If not Settings will be styled with adwaita or whatever your distro has decided to rework libadwaita with.

The reason for raising this as a discussion point is the reliance on the 10.x series of budgie desktop with GNOME Settings.

Is there any desire to extend budgie-desktop-settings to support what is functionally available from GNOME Settings?
As far as I can see quite a bit of GNOME Settings maps onto mutter and/or gnome-settings-daemon schemas so the effort here would be
a) understand the relationship
b) implement a new budgie settings page with the relationship mapping
c) find a great icon designer for the new settings page
d) add strings for translations

There are various parts on GNOME Settings such as Displays that will take quite some thought/effort to-do I guess. So this all may be a big rabbit hole to jump down into.

If there is no desire for this - fair enough. The budgie community will I'm sure (eventually) accept the situation with the view on budgie 11 on the horizon.

[Drsheppard01]

As the days grow longer, the storms are stronger

as gnome and budgie evolve, the settings will have less and less compatibility. I think I should create a fork of gnome settings now. why? example: in opensuse, my gnome settings broke when selecting the Multitasking section with an error: Glib-schemas error: settings schema org.gnome.shell.app-switcher is not set

[fossfreedom]

There is that perceived confusion though - two places for GUI configuration which will be exacerbated by such a fork.
Some distros I doubt will be able to "hide successfully" GNOME Settings since it will be delivered into budgie desktop as a dependency/recommendation on another gnome component budgie depends on . Thus could be in the situation of 3 potential UIs for configuration.

[Drsheppard01]

the main idea is to make a fork of the settings and implement the budgie desktop setting and slick-greeter settings, for example. To carry out the necessary optimizations and work with this fork

[fossfreedom]

hmm ... interesting reverse psychology idea :) - guess it comes down to how long to strip out the stuff from the GNOME 40 version of gnome-control-center and then reimplement budgie-desktop-settings within the g-c-c codebase vs the other way around.

Looks like g-c-c has a lot of legacy code doing who knows what. Its certainly not a codebase I'm familiar with so kind of difficult for me to gauge risk vs reward.

[JoshStrobl]

Thanks for opening up this discussion. So forking GNOME Control Center for Budgie was something I was originally going to do in Solus land, for the following reasons:

1. Currently uses libhandy
2. As you mentioned, will use libadwaita going forward.
3. Can result in segfaults that can't really be properly recovered from if you use specific sections, like Workspaces, while under Budgie. As @Drsheppard01 mentioned.

I have added a fair few patches onto Solus' version to address at least point 3 and @serebit had added a patch to introduce some mouse acceleration functionality as well.

I do not believe that Budgie Desktop Settings in 10.x should incorporate settings from GNOME Settings. When you break it down, that is a ton of work that I'm just not sure is worth the time investment, given it'd be nuked for 11. You'd end up having to:

1. Implement networking functionality
2. Implement bluetooth functionality
3. Implement background setting functionality and loading
4. Re-architect notifications and make sure Budgie Desktop is up-to-date to check those filters
5. Implement some sound management (mostly handled by Raven already, but still may be useful for some folks)
6. Implement display management
7. Implement all the mouse settings
8. Printer support, nobody wants to touch that but it'd need to be done
9. Accessibility is important and our user story around that is subpar at best currently.
10. User management
11. NTP related stuff

That is minimum viable product really. What I would propose is:

1. Fork GNOME Control Center from pre-libhandy days to reduce workload from reverting all that. Rebrand it, remove GNOME Shell specific functionality, possibly remove panels like Applications & Privacy that are mainly flatpak oriented and there are third-party solutions if the user desires) and make sure it doesn't conflict with GNOME Control Center.
2. Investigate viability of merging Budgie-specific functionality into our new fork. This may be slightly cumbersome for things like panel management, just because of how that is architected at the moment, but it would serve as a good model for Budgie 11 since all of that would be over DBus (or similar protocol + layer) anyways.
3. Incorporate desired changes / added functionality where sensible, feasible, and does not negatively impact our ability to work on the rest of the "stack" for 10.x. For example, exposing functionality for existing "keys" like @serebit did for mouse acceleration. Plenty of candidates that can be found in GNOME Tweaks (background span as an example)

What are you thoughts?

[JoshStrobl]

If you have any ideas on what we could to do facilitate Raspberry Pi support in a way that wouldn't introduce libhandy, that'd be ideal.

[fossfreedom]

ok - its not the fact that its a Pi - the key issue here is that we always consider keeping/enabling a responsive interface.

In a separate thread we are discussing tiling options - e.g. horizontal tiling. When you do this on a standard laptop you immediately run into resolutions that apps needs to shrink to (1024px screen - tiled by half is 512px height for each app)

Fixed sized apps cause major frustrations I'm sure for you as well as for me where you want to multiple apps simultaneously on the screen - e.g. terminal, settings, text editor at the same time.

As I mentioned previously I'm not really into the perceived politics and nature of components - if things work and enables keeping the modern dynamic nature of todays desktop then its a win for me. We are talking here of looking at a v0.0.1 solution for the immediate concern all budgie users will encounter in the next few months. I'm sure we all want a quick win here - least effort for max impact.

There aren't any real quick wins here other than ensuring viewports/scrollbars are added around the two main parts of g-c-c. Not completely dynamic but allows a semblance of flexibility that current GNOME 40/41 versions of g-c-c has.

[guillotjulien]

I personally don't have anything against libhandy usage in Gnome Control Center. This app is what I'd call a "good citizen" as the desktop experience don't end up being deteriorated.

Now we also have to consider than going forward, libhandy won't be maintained given that the focus switched to libadwaita which we can't use given that it's GNOME specific. IMO we can easily achieve a similar result by simply using FlowBox and scrollbars (and maybe a revealer for the navbar). Later for B11, we could even create a desktop agnostic library whose only focus is around layouting if we need it.

[JoshStrobl]

Okay so in light of this discussion, I do feel compelled to fork GNOME Control Center at 41 where it is currently using libhandy, in recognition that I do not want to compromise the experience for Raspberry Pi users on Ubuntu Budgie. If we eventually get to the point of having a UX for it that can scale down without the need for it, great, but I'm not going to cause frustration for that userbase otherwise.

[JoshStrobl]

Fork now up at https://github.com/BuddiesOfBudgie/budgie-control-center