Redesign main lists based on GNOME HIG

[nana-4]

Mockup:

based on: https://developer.gnome.org/hig/stable/lists.html.en

Some design examples from GNOME's mockup:

• https://gitlab.gnome.org/Teams/Design/settings-mockups/blob/master/applications/applications-wires.png
• https://gitlab.gnome.org/Teams/Design/app-mockups/blob/master/tweaks/tweaks-wires.png

[actionless]

i think the bigger problem which should be addressed in the list of the options, is to make some easier navigation.

currently, especially if terminal theme set to Manual mode, that list have way too many items to scroll, so i was thinking mb about some Notebook tabs or smth like that

do you have any ideas on how to address that kind of problem with the list?

[actionless]

also i can't understand which style classes should i use to achieve the same appearance as shown on your mockup or in HIG -- when i installed gnome-tweaks (3.30.2) it looks totally different:

i only can see in HIG they mentioned as "embedded lists" but i can't see anything related in the apidoc: https://developer.gnome.org/gtk3/stable/GtkListBox.html

[nana-4]

i was thinking mb about some Notebook tabs or smth like that

I also had an idea to use tabs or something like that. I'll create a mockup for that.

when i installed gnome-tweaks (3.30.2) it looks totally different

gnome-tweaks has not adapted that style yet. Please try gnome-control-center -- which should be the best example so far.

[actionless]

seems it's not gonna work without actual gnome running :(

$ gnome-control-center
**
ERROR:../gnome-control-center/shell/cc-shell-model.c:458:cc_shell_model_set_panel_visibility: assertion failed: (valid)
fish: “gnome-control-center” terminated by signal SIGABRT (Abort)

[actionless]

gtk inspector is using such layout but idk how to inspect it with itself

[actionless]

mb you could just make a screenshot of CSS nodes tree of the appropriate layout (with screenshot of that app itself)?

[nana-4]

Of course! Here you are:

Please let me know if you need more screenshots.

[actionless]

thanks! i'll try to play with it tonight or tomorrow morning!

[actionless]

and also please think about some quick-navigation for the list, like splitting into tabs, or scrolling the list based on stackswitcher buttons or so on

[actionless]

unfortunately info from CSS Nodes tree is not enough for recreating this :(
mb you know starting from which version gnome-tweaks having that layout so i can just open that tag from their repo and observe the code?

[actionless]

or mb after we'll get some solution for navigating/splitting this long list such design approach (with "white" blocks) won't be applicable anymore so mb better first to design that navigation/splitting into tabs/whatever?

[nana-4]

mb you know starting from which version gnome-tweaks having that layout so i can just open that tag from their repo and observe the code?

Unfortunately, the mockup is only available but in real application it has not been applied yet :(

or mb after we'll get some solution for navigating/splitting this long list such design approach (with "white" blocks) won't be applicable anymore so mb better first to design that navigation/splitting into tabs/whatever?

I agree. I'd like to create some mockups, but I don't have much time to do it. Sorry, but I'll address it soon.

[actionless]

no worries, i also time-limited and apart from GUI redesign i am also doing some other small improvements to the app

for example yesterday i've added inhibititing logout/poweroff if there is unsaved themix theme

[nana-4]

Thanks. I've created the mockup for navigating/splitting the long list. Please check it and let me know your thoughts.

Here's the options screen of "Image Colors" (maybe "Base16 Options" will also have a similar screen?):

Some notes/additional ideas:

• I didn't choose tabs (GtkNotebook) style because it'll have a white background under the white lists.

• As shown in the mockup (of Icons), I think "Numix Style" option should be merged into the "Icons Style" option. (At least to me, "Numix Style" option is not very easy to understand. Honestly, I didn't understand what "Numix Style" is until recently.) I suggest removing the "Numix Style" option and making the "Icon Style" menu items like the following:

  • Archdroid
  • GNOME-Colors
  • Numix 1
  • Numix 2
  • Numix 3
  • Numix 4
  • Numix 5
  • Numix 6

• If the only "Theme Options" section in Numix-based is too much, adding "Advanced Theme Options" section might be useful. (I think "Caret Aspect Ratio" and the "Outline" options could be placed in that section, if needed.)

[actionless]

thanks!

regarding Numix Style, that's separation is based on the following logic: Archdroid, Gnome-Colors and Numix-Icons are 3 different plugins, so first dropdown is selecting plugin. Next Numix-Icons have it's own plugin option, called Numix-Style, which at the end passing different arg to numix icons generation script. So if you want to improve, the only thing which can be done here is renaming those items, but they can't be merged together. Mb, "Numix Icons Variant"?

[actionless]

Also regarding StackSwitcher sections:
i think it will be better to have instead of Spotify "Other" theme section, and put there everything what is under terminal theme options (including spotify).

from technical side of view, i mean the content of plugin's theme_model_extra theme options list

[actionless]

And also about design for import options (with cog wheel icon):
i think it should be the leftmost in stackswitcher, not rightmost
just from the logic what import is on the left of the topbar and also what usually those import options are meant to be accessed first before editing theme options -- because changing import options would overwrite manual theme options changes (but it will show a prompt dialog about that before)

[nana-4]

So if you want to improve, the only thing which can be done here is renaming those items, but they can't be merged together. Mb, "Numix Icons Variant"?

Ah, I see. IMHO, "Numix Icons Variant" still sounds a bit ambiguous. I think it would be better to rename it to "Folder Icons Style" (which sounds much clear to me).

i think it will be better to have instead of Spotify "Other" theme section, and put there everything what is under terminal theme options (including spotify).

I think it would be better to separate the "Terminal" and "Spotify" sections for better handling of the "Export" buttons (#185). Please take a look at the blue "Export" button in my new mockup. In my new idea, pressing the "Export" button while in "Terminal" section will export the terminal palette, and so on.

And also about design for import options (with cog wheel icon):
i think it should be the leftmost in stackswitcher, not rightmost
just from the logic what import is on the left of the topbar and also what usually those import options are meant to be accessed first before editing theme options -- because changing import options would overwrite manual theme options changes (but it will show a prompt dialog about that before)

Ah, right. I agree with it. (The reason why I put it on the rightmost is because I thought that import options seemed quite technical, so it could be hidden on the rightmost for non-expert users.)

[actionless]

"Folder Icons Style"

👍

I think it would be better to separate the "Terminal" and "Spotify" sections

yup, i was thinking of "Theme, Icons, Terminal, Other", especially keeping in mind what in Flatpak installation Spotify plugin is not available at all

. In my new idea, pressing the "Export" button while in "Terminal" section will export the terminal palette, and so on.

the number of export plugins is not limited, so it could became a bit misleading what one plugins are exporting their result implicitly on Export button and other would require explicitly selecting them in the export menu

import options seemed quite technical, so it could be hidden on the rightmost for non-expert users

i think in the minimal scenario it's usually enough to use only import options, without manually modifying any others, since in import options you could choose some of pre-defined theme templates

[nana-4]

from technical side of view, i mean the content of plugin's theme_model_extra theme options list

Ah, do you mean that the "Desktop Environments" section should be in the "Other" stack? If so, I have no idea why you think that is better... IMO, theme_model_extra options should be merged into theme_model_options and should be handled in the "Theme" stack.

the number of export plugins is not limited, so it could became a bit misleading what one plugins are exporting their result implicitly on Export button and other would require explicitly selecting them in the export menu

So, how about changing the "Export" button label depending on the stack-switcher button? For example, while on the "Terminal" stack, the blue button label will be "Export Terminal".

[actionless]

in the theme plugin which you linked it's already merged, the line which you're pointing is commented out

theme_model_extra was aimed for exports which are not covered by normal Export Theme flow, like at the moment Spotify (but i hope more export plugins will come with the time)

So, how about changing the "Export" button label depending on the stack-switcher button? For example, while on the "Terminal" stack, the blue button label will be "Export Terminal".

that could be better from the point of clarity though i still think this (#185 (comment)) approach would be more straight-forward and discoverable

[nana-4]

Ah, I only searched for theme_model_extra in this repo and didn't know it exists in the oomoxify repo. Sorry.

However, I still think it would be better to have to have the "Spotify" stack (etc.) instead of "Other" stack. I think that should be more clear.

that could be better from the point of clarity though i still think this (#185 (comment)) approach would be more straight-forward and discoverable

Honesty, I'm not a fan of it. It still quite wastes the headerbar width. Also I'd feel strange if there are other "Export (Theme|Icons|Spotify)" buttons while on the "Terminal" stack.

[nana-4]

BTW, I found another app with lists based on HIG. Please try Podcasts.

[actionless]

However, I still think it would be better to have to have the "Spotify" stack (etc.) instead of "Other" stack. I think that should be more clear.

i explained what Spotify is just plugin, not part of the app, especially keeping in mind what in Flatpak installation Spotify plugin is not available at all

wastes the headerbar width

could you just for a reference make a screenshot? because in AwesomeWM (with normal window decorations so without titlebar buttons in CSD) it looks quite clean

[actionless]

Please try Podcasts.

thanks, i'll check it tonight

[nana-4]

i explained what Spotify is just plugin, not part of the app, especially keeping in mind what in Flatpak installation Spotify plugin is not available at all

How about any of these?

• If Spotify plugin is not available, hide "Spotify" button from stack-switcher.
  • Or make "Spotify" button disable.
• Or make Spotify plugin part of the app (if possible). I always wondered why Spotify is handled in the different repository despite Terminal is part of the app.

could you just for a reference make a screenshot?

I took some screenshots with several themes on GNOME Shell with minimum window size.

Adwaita:

Materia:

Arc (with all window control buttons):

Numix (with all window control buttons):

On GNOME with minimum window size, "Export Theme" button is almost in the center, and the window title is almost omitted.

because in AwesomeWM (with normal window decorations so without titlebar buttons in CSD) it looks quite clean

Also Numix/Oomox has narrow side padding in button.text-button, but most other themes are not ;)

[actionless]

Or make "Spotify" button disable.

i want to make less logic in app itself, because it's always better architecture when there is a minimalistic core which provides common API for plugins rather than implementing each case separately

looking on the screenshots i think what, given "Export Terminal" is the longest label and what .linked style will reduce inter-button spacing, i think it should address the problem with too much ellipsis-ed title. Also after refactoring left sidebar application have a minimal width, so user can't resize it to became too small to make any of top controls unreachable

Oomox has narrow side padding in button.text-button

i was actually fixing it yesterday :-) https://github.com/themix-project/oomox-gtk-theme/compare/5487d169d14a4c0000c3a127ccca68cb3e7210cd...39812f4b499a9416537338908e1f4c56a1bb1148?short_path=0a60202#diff-0a60202ac48d230771cccdf80f55b285

[nana-4]

I rather moved "Save" etc. to the right, with an opposite idea:

• Left panel is the list of presets, so "Import (something to the list)" button is on the left.
• Right panel is the edit screen of the current preset, so "Save (current preset)", "Save (current preset) as...", "Rename (current preset)" and "Delete (current preset)" are on the right.

For reference, these GNOME's mockups (todo & notes) are also based on same idea.

on the left of the panel there are actions which apply to presets

If actions are against all the presets in the list (or against list itself), I would have agreed they are on the left...

[actionless]

after looking on the mockups i see what your proposal totally inline with them

however looking on the mockups i see one important difference:
in the mockups they're using Burger menu for app-level actions, and 3-vertical-dots menu for item-level actions. while in your mockups both are residing under Burger menu (which seems semantically incorrect)

also let's keep headerbar discussion inside this thread: #185

[actionless]

it's almost a year passed, but unfortunately GTK3 still doesn't have (doesn't have documented?) the widgets or style classes to make such a design for main lists to happen

in gnome-tweak-tool and gnome-control-center it seems they just have some custom styling or so (at least that's what i see from gtk inspector)

[nana-4]

Yep, it seems such a design is realized by using .ui files in all GTK3 apps (at least as far as I can see).

For example:
https://gitlab.gnome.org/GNOME/gnome-control-center/blob/master/panels/universal-access/cc-ua-panel.ui#L108
https://gitlab.gnome.org/World/gcolor3/blob/master/data/window.ui#L177

(So sorry for my long silence.)

[actionless]

ok, thanks a lot @nana-4
i think i'm getting somewhere with that:

[actionless]

still looks a bit crappy but moving somewhere :)

[actionless]

hm, but it seems what the further work would first require me to refactor the theme model as it stored in plugins from being just a list into being some structure what will be split into sections (now section names are just parts of the list together with actual theme values/options)

[actionless]

@nana-4

sorry for the delay on this issue :)

finally got to finish it, please check on this branch: https://github.com/themix-project/oomox/tree/redesign-main-lists

[nana-4]

@actionless My apologies for the late reply...!

I tried the branch, it looks very nice! Great job! 👍

I think this is already close to perfection, but I think it would be even better if you could do these things:

• Add separators between the list rows, like my mockup.
• Remove less meaningful hover/active effects from the list rows (perhaps by setting activatable=FALSE).
• Add a vertical GtkSeparator between GtkPaned and the theme preview, like my mockup.

And personally I'd still prefer to separate the Theme Style and Theme Colors into separate sections (otherwise, end users may misunderstand that the Theme Options is independent of the Theme Style.), but I'll leave the decision to you :)

[actionless]

Add separators between the list rows, like my mockup.

such separators should be defined in GTK theme, not as a border widget (you can see gtk-inspector on the left as an example)

Remove less meaningful hover/active effects

Add a vertical GtkSeparator between GtkPaned and the theme preview, like my mockup.

to separate the Theme Style and Theme Colors into separate sections

good points, thanks

[nana-4]

such separators should be defined in GTK theme, not as a border widget (you can see gtk-inspector on the left as an example)

Looking at gtk3-widget-factory's code, apparently it actually calls GtkSeparator for the list box on "Page 2" by using gtk_list_box_set_header_func () and its own update_header (). Thegnome-control-center application also uses a similar function.

But I don't know if such a method can be applied to this project. So, I'm OK without the separators 👌

[actionless]

i see it now in gtk3-widget-factory, that's quite weird what they have the same element styled differently across default apps

does they have any HIG part describing it?

[nana-4]

https://developer.gnome.org/hig/stable/lists.html.en

In standard lists, each row is divided by separators,

This means you can optionally remove the list separators, I guess?

Typically, GNOME apps have separators in list boxes that contain action controls in each row. Lists that don't contain action controls, such as sidebars, usually don't have a separator for each row.

The lists in the GtkInspector seems to deviate from the typical design. I think GNOME designers weren't very involved in the design of it...

[actionless]

after looking on the HIG (which assumes those separators to be smth standard which they are not) i'm even more grounded in the theory which i had yesterday about it :)

the theory is what

1. by design they wanted all list items to have the separators
2. they added those borders in the gtk theme
3. it broken visually some of the popular third-party gtk apps
4. they moved borders' definition from the theme to the app

[actionless]

@nana-4 i've tried to implement all of your recommendations, please check on the master branch

[nana-4]

2. they added those borders in the gtk theme

According to my memory and a little search, the default GTK theme had never defined borders for each list row. But now, GTK4 has a boolean GtkListBox:show-separators and the separators are drawn by theme :)

[nana-4]

@nana-4 i've tried to implement all of your recommendations, please check on the master branch

Looks awesome! Thanks!

One remaining issue: Can we avoid using a list for Theme Style, and make it like my mockup? GNOME apps don't use a list if it has only one item. And the GNOME HIG says:

Do not use lists with fewer than about five items, unless the number of items may increase over time.

[actionless]

regarding separators, yeah, i know it wasn't released, but just judging from mockups and related HIG -- it seems it was designed to be, but they either tried that locally or realized without trying what it might break things visually. but anyway that was just a lyric sidenote after reading that HIG :)

---

regarding list items

it falls under

unless the number of items may increase over time.

because programmatically it's just one of theme sections, the same as others below (or above, if in plugin mode)

[nana-4]

because programmatically it's just one of theme sections, the same as others below (or above, if in plugin mode)

OK, that's fine then 👍

[actionless]

thanks for your input and feedback!

[nana-4]

Thanks for your great work and feedback too :)