feat: libadwaita preferences

[bennypowers]

Closes #173
Closes #217

This draft PR migrates various preferences widgets to libadwaita

So far, I've just done the color widgets inside the color panel.
If maintainers are interested, my plan is to work on the "leaf nodes" first - the individual pref widgets, and when those are all done, move on to the views, using tab pages and other adw containers

[jmmaranan]

Hi @bennypowers, thank you for incoming the contribution. I would agree preferences needed the makeover. I can't wait to try it out

[bennypowers]

I've migrated most pages to adw

this removes many lines of code, which is nice

still to do

• figure out why most of the icons don't work
• fix the tabbed/stacked dropdown
• implement the keyboard page
• i might refactor colours and other prefs to connect to the settings schema one-to-one, and use .ui files for the prefs
• i might implement quick settings

[bennypowers]

As of 526e0f7, all the prefs pages are implemented in terms of adwaita concepts and widgets.

Somewhere along the line, I think I broke the schemas, since dconf tells me I have nothing at dconf list /org/gnome/shell/extensions/forge/keybindings/, so that will have to be fixed before merging.

As well, I still would like to make the css prefs write to the prefs db and have updating the theme be a side effect of db changes, like how blackbox does it

More Screenshots

[bennypowers]

Ok this is ready for review. I'm sure there are lots of small things that I overlooked, and code style changes that you'd like to make.

I'd still like to refactor the colour preferences, but doing so without breaking backwards would be difficult, so that should wait for a further PR

[jmmaranan]

Hi @bennypowers,

Overall, it looks great and refreshing

• My wish is that if we can bring back the state icons when the tiling mode is in workspace float, tiling off or on.
• For the text, I would like your opinion on having the messages.js to contain the messages or we define any text directly on the place they are being used going forward. And then perhaps provide styleguide of some sort going forward
• We can drop < 43. I assume just retaining 43, 44 in the metadata.json

[bennypowers]

Thank you for the feedback. I will implement a "settings" window that combines experimental and developer

For the icon, what if we kept the "indicator only when on", but updated the quick settings icon depending on state?

[jmmaranan]

Thank you for the feedback. I will implement a "settings" window that combines experimental and developer

Sounds good. The developer section is tied to the production switch.

For the icon, what if we kept the "indicator only when on", but updated the quick settings icon depending on state?

• The Panel icon (along with wifi, etc), would have the same behavior as it is today (and one small change on the Workspace floating icon - more on below). Icon only gets removed when Forge is disabled or uninstalled from Ext Manager or similar.
• When Tiling is Off or the current workspace is floating, Quick settings icon should be the icon you used on the quick settings - showing as two separate boxes / windows. For the Panel icon, use the same two boxes icon. The current production workspace floating icon is different but let's drop it. So that there are only two icons to keep it simpler.
• When Tiling is On or the current workspace is Tiled, Quick settings icon should be the current production tiled icon. You already got the panel icon correct on this PR.

Summary:

• Two columns icon (Tiling ON/Workspace Tiling ON)
• Two boxes icon (Tiling Off / Workspace Tiling Off)
• Panel icon / Quick settings only disappears when Forge is disabled or removed

[bennypowers]

Ok I'll take a look, that might be contrary to the HIG though. The built-in class and tutorial says

You may also want your extension to show a panel indicator when the feature is enabled.

Compare that to how the night light or WiFi panel icons work. The intent of the quick settings panel is to remove information from the panel whenever features are disabled

[jmmaranan]

Ok I'll take a look, that might be contrary to the HIG though. The built-in class and tutorial says

You may also want your extension to show a panel indicator when the feature is enabled.

Compare that to how the night light or WiFi panel icons work. The intent of the quick settings panel is to remove information from the panel whenever features are disabled

If that's the case, let's follow the interface guidelines and please update the icon to view-grid-symbolic instead:

Again, thank you for your time and effort on this. 👍🏼 Just waiting for the Experimental and Developer sections and I think it should be good to be merged.

[bennypowers]

• Merged Experimental and Developer into "Settings"
• Make "Settings" first page
• Rename "experimental" group to settings and add an "experimental" flag to switch widget
  • to complete goals of feat: optimize/update preferences window #217, just remove experimental: true from settings which have "graduated"
• Added an AdwAboutWindow accessible by clicking a header button in "Settings"
• Derive contributor metadata from git log and present that in About
• Remove panel button / drop support for GNOME < 43
• Remove make dev and add make text-{x,wayland}

[bennypowers]

I moved some preferences around and refactored in c56f5fe. most of the changes wre "best guesses"

[jmmaranan]

This looks really good to me. Thank you! I just gave the AUR packager a heads up. I think they were using make build - but I will go ahead and merge this.

[jmmaranan]

@bennypowers - looks like your focus hint changes was not rebased when you started this branch, do you know if you can fix that?

[bennypowers]

ok i see, I merged instead of rebasing. hopefully the gnarly rebase didn't break anything. I ran a quick test and it looked ok

[bennypowers]

Amazing! let's celebrate with a bowl of San Antonio Chili 🌶️ 🍖 🧅

[jmmaranan]

It's sent to extensions gnome dot org for review