feat: Gradience UI/UX redesign

[tfuxu]

Feature description

Currently, Gradience is a tool for making custom presets for libadwaita and adw-gtk3 themes, but this is gonna change soon, when we introduce a Shell theming ability in 0.8.0, and a GDM theming in a near future. The fundamental usage of Gradience will change from a tool for changing colors in libadwaita applications, to a one-stop shop for GTK/GNOME (and maybe even Qt) theming. We will need to rethink the layout and a general look and feel of Gradience to not confuse the user, and also to comply with HIG.
This issue thread will be used to discuss the potential ideas and suggestions for a new Gradience user interface.
_{The approximate milestone for a new user interface: version 1.0.0}

Currently available ideas/concepts:

Core UI:

• New main window design idea (comment)

Theme Engines:

• Theme Engines window (comment)
• Theme Engine wizard (comment)
• Wizard preferences idea (comment)

Additional Context

No response

Did you read the Code of Conduct?

• I have read the Code of Conduct.

[tfuxu]

Idea description:

My idea would be to move preset manager as a first tab in Gradience's main window (so replacing current preset editing suite with the preset management).

There will be a wizard for creating a new preset, and every preset row will have a Edit Preset button which will open a new window with a current Preset tab layout. Preset rows will have an Load and Apply buttons. Load will load a preset in Gradience for preview. Apply will apply a preset onto system.

Apply button on the main window's headerbar will be useless, so it will be replaced with New Preset button, that will open a New Preset wizard.

Alternative Apply button idea

Apply button on the main window's headerbar will be useless, so it will be replaced with New... menu button with Preset and Theme options. Preset option will open a New Preset wizard and Theme option will open its own New Theme wizard in which you will need to select a theme engine you want to use, and an input preset from which the theme will be generated.

There are some things that need to be considered for this idea, for which I don't yet have any concepts, like where should an Explore tab from preset manager be located, and what to do with tabs in main window (e.g. should we move plugins to preferences?, where Monet Engine should be located?).

[daudix]

There is Schemes app from which we can take inspiration

[daudix]

[tfuxu]

Idea description:

This is an extension of a previous idea, focused on plugins.

First type of plugins

Custom Python modules (aka classic plugins). They will be replaced with the Theme Engines (new concept that's being added in Shell theming PR), and they will use an new, in-house plugin system (in short, Gradience will limit available amount of backend functions, by only exposing in future gradience.api.* modules).

There will also be an distinction between Theme Engines (e.g. Shell Theme Engine) and Preset Engines (e.g. Monet Engine). The first type creates themes for other applications / frameworks from presets, and the second type generates presets from different data than color formats.

Official built-in plugins will include at least theme engines that complete consistent GNOME look. This will include: Shell theming Engine and planned GtkSourceView Engine. There will be some additional plugins (like planned one for Adwaita for Steam) that will be available to install as a Flatpak plugin or from setup screen on native builds. Engines will be managed from a dedicated section in preferences.

Second type of plugins

Custom preset variables lists. Users will be able to import custom lists from other users that will contain additional variables for different GTK applications that use custom styles. For now this is just a simple idea with no specifics, as firstly we need to consider how should this even work.

[0xMRTT]

@tfuxu I like the first proposal

[daudix]

I really like the idea of theming engines and preset engines, good idea!

[tfuxu]

Concept window for Theme Engines selection from first proposal:

[tfuxu]

Also, if we would go with Theme Engines wizard concept, I think we should implement an export of options selected in wizards, something like how unattended installation works on Windows with its answer file. Users will also be able to select to either do actual unattended wizard or to just fill out widgets with user-defined values.

It would probably be managed in JSON format with a filename looking somewhere like this: theme-engine-name-prefs.json.
The structure of the file itself will be divided into individual wizard pages which will contain names of preferences with values changed by the user.

Here's my proposed prototype of the preferences file:

{
  "skip_pages": true,

  "page_1": {
    "custom_theme_name": "My awesome theme",
    "export_theme": true
  },
  "page_2": {
    "shell_version": "autodetect",
    "recolor_widgets": false,
    "radius_size": 14
  },

  "other_prefs": {
    "custom_css": "headerbar {height: 14px}",
    "border_size": 20
  }
}

other_prefs is a preferences container which can hold user-defined values from child windows, like Custom CSS Editor window.

This feature could be useful for users who make a couple of colorstyles simultaneously, as selecting all of the options for each preset would be pretty irritating, especially if we would make engines for more extensive apps / frameworks. It would be also useful for people who simply experiment a lot with different colorstyles.

[tfuxu]

Here's the first prototype of Theme Engine wizard window:

Welcome Screen:

General Screen:

Web Theme Screen:

Wizard Finished Screen:

The wizard window will be more generic (so it could be used with other Theme Engines) in the later revisions, I just made it with Adwaita for Steam prefs for now, because it better presents itself when some widgets aren't just placeholders.

CC @daudix-UFO What do you think about this design? It will definitely need some more work, especially with the welcome page, but I think that the rest of the pages already look pretty good.

Here's a .blp file of the prototype: https://gist.github.com/tfuxu/0027582ef1edab807b0379a429bd8f92

[tfuxu]

Also, those grayed out rows are just ComboRows without any StringLists attached

[daudix]

I think all pages look pretty good, but yeah, welcome page needs some work (like make it more centered, as now it have all contents floating on top)

[0xMRTT]

Also @tfuxu maybe we can add check so user will not complain if the theme isn't working because they didn't installed the required tools... And maybe we can add a link to a script for pre setup and post setup?

[daudix]

I think we should make Gradience more "smart" in general, so it will be able to:

• check for gtk-* config folders permissions and change them if needed
• check if "bad" extensions is installed and request to disable them
• install adw-gtk3 to .local/share/themes and as flatpak if it's detected in system
• fix flatpak theme overrides
• and etc

Most of this will require additional Flatpak permissions, but as Gradience is not a regular app I think it's ok (maybe we can ship gradience with minimal amount of permissions and then enable needed ones when they are needed)