Redesign User Preferences #54115

New Issue

Julian Eisel · 2018-02-21T11:08:52+01:00

Julian Eisel commented

2018-02-21 11:08:52 +01:00

Motivation

There are two main reasons why the User Preferences need an overhaul:

Outdated/aging design


When the current User Preferences design was created, there were much less
options than there are now. As more were added, the User Preferences became
a pretty polluted place. Finding options in it became increasingly harder and by
now it's just not pleasant to work with.

New concepts don't fit into current design

2.8x introduces new concepts that require new kinds of settings. One being

workspaces, which users can set up to their liking and store in a custom
configuration. This configuration is separate from the user preference
configuration (userpref.blend vs. workspaces.blend) so their setup should not
happen in the regular User Preferences.
Another new concept was splitting system settings apart from User Preferences.
The system settings would be purely for the current work station and its devices
(GPU usage, monitor configuration, pen/touch tablet options, etc.)

{F2332801} *Diagram by @ton from [[ https:*code.blender.org/2016/12/highlights-of-workflow-workshop/ | here ]].//

Proposed Design

I'd propose a design that is similar to how many applications, websites and operating-systems (or desktop environments) do it:

Notable suggestions are:

Rename the User Preferences window to "Settings".

The window would now show more than just user preferences, so it should be renamed
accordingly.

Increase size of Settings window.

The current size of the User Preferences limits us too much in space. We end
up cramming together options quite a bit, even though some more whitespace
would increase readability.

Have two levels of grouping, first the "category" (User Preferences,
Workspaces, System), then the settings-"group" (Interface,
Add-ons, Theme, Devices, etc.). Of course "category" and

"group" are tentative names.

Add a search button to search for settings.

Note that the mock-up shows changes to the theme-system as well. These are not part of this proposal. Changes like that can be checked on separately as we go more into details.

Rationale

A design similar to the one proposed, should bring multiple benefits:

Allows having a central place for user preferences, plus the new workspace

and system settings.

Options can be placed in a more structured and readable way.
The design is more extensible in that new categories or groups can be

added as needed. Old one was too static (as in, we tried to fit everything into
the few existing categories).

The term "Settings" is often used in other applications and should therefore

be easier to find for novice or occasional users.

Many applications and websites use a similar design. That should make it

easy to learn for both new and existing users.

A search button should hugely increase usability of the Settings window, as

it's not untypical to search a very specific option.

Workload

Although there may be some challenges, I expect this redesign to be a nicely isolated task where we can do much good with rather little effort. Definitely a doable change for 2.8. Especially since it allows us making the workspace configuration more flexible & useful (we don't have a proper UI for that yet).

We may have to add special widgets for the category/group chooser, but a temporary solution using existing widgets would work too.

I wouldn't mind working on a prototype and transforming it into a ready-to-use state once the design is agreed on. A nice task for until we know how to continue with the topbar.

References

I did do some research before opening this, in fact the proposed solution is based on this KDE-settings mockup: *More mockups using this design here //.

Other useful references:

## Motivation There are two main reasons why the User Preferences need an overhaul: * **Outdated/aging design** ``` When the current User Preferences design was created, there were much less options than there are now. As more were added, the User Preferences became a pretty polluted place. Finding options in it became increasingly harder and by now it's just not pleasant to work with. ``` * **New concepts don't fit into current design** ``` ``` 2.8x introduces new concepts that require new kinds of settings. One being ``` workspaces, which users can set up to their liking and store in a custom configuration. This configuration is separate from the user preference configuration (userpref.blend vs. workspaces.blend) so their setup should not happen in the regular User Preferences. Another new concept was splitting system settings apart from User Preferences. The system settings would be purely for the current work station and its devices (GPU usage, monitor configuration, pen/touch tablet options, etc.) ``` ``` {F2332801} *Diagram by @ton from [[ https:*code.blender.org/2016/12/highlights-of-workflow-workshop/ | here ]].// ``` ## Proposed Design I'd propose a design that is similar to how many applications, websites and operating-systems (or desktop environments) do it: ![blender_settings_02.png](https://archive.blender.org/developer/F2332787/blender_settings_02.png) Notable suggestions are: * Rename the User Preferences window to "Settings". ``` The window would now show more than just user preferences, so it should be renamed accordingly. ``` * Increase size of Settings window. ``` The current size of the User Preferences limits us too much in space. We end up cramming together options quite a bit, even though some more whitespace would increase readability. ``` * Have two levels of grouping, first the "category" (*User Preferences*, *Workspaces*, *System*), then the settings-"group" (*Interface*, *Add-ons*, *Theme*, *Devices*, etc.). Of course "category" and ``` "group" are tentative names. ``` * Add a search button to search for settings. Note that the mock-up shows changes to the theme-system as well. These are not part of this proposal. Changes like that can be checked on separately as we go more into details. ## Rationale A design similar to the one proposed, should bring multiple benefits: * Allows having a central place for user preferences, plus the new workspace ``` and system settings. ``` * Options can be placed in a more structured and readable way. * The design is more extensible in that new categories or groups can be ``` added as needed. Old one was too static (as in, we tried to fit everything into the few existing categories). ``` * The term "Settings" is often used in other applications and should therefore ``` be easier to find for novice or occasional users. ``` * Many applications and websites use a similar design. That should make it ``` easy to learn for both new and existing users. ``` * A search button should hugely increase usability of the Settings window, as ``` it's not untypical to search a very specific option. ``` ## Workload Although there may be some challenges, I expect this redesign to be a nicely isolated task where we can do much good with rather little effort. Definitely a doable change for 2.8. Especially since it allows us making the workspace configuration more flexible & useful (we don't have a proper UI for that yet). We may have to add special widgets for the category/group chooser, but a temporary solution using existing widgets would work too. I wouldn't mind working on a prototype and transforming it into a ready-to-use state once the design is agreed on. A nice task for until we know how to continue with the topbar. ## References I did do some research before opening this, in fact the proposed solution is based on this KDE-settings mockup: ![Tablet 9″.png](https://archive.blender.org/developer/F2333236/Tablet_9_.png) *More mockups using this design [here ](https:*phabricator.kde.org/M112/416/)//. Other useful references: * [KDE system-settings design discussion ](https://community.kde.org/KDE_Visual_Design_Group/System_Settings_Application). * [GNOME system-settings design research and discussion ](https://wiki.gnome.org/Design/Apps/Settings).

Julian Eisel commented

2018-02-21 11:08:52 +01:00

Added subscriber: @JulianEisel

Antonio Vazquez commented

2018-02-21 11:14:21 +01:00

Added subscriber: @antoniov

Duarte Farrajota Ramos commented

2018-02-21 11:52:15 +01:00

Added subscriber: @DuarteRamos

Julian Eisel commented

2018-02-21 12:19:53 +01:00

Added subscriber: @Ton

Joshua Leung commented

2018-02-21 13:49:21 +01:00

Added subscriber: @JoshuaLeung

Joshua Leung commented

2018-02-21 14:36:56 +01:00

In general, I don't have any major objections to the stuff proposed here.

Various random points (even though we're still just dealing with rough ideas here atm):

Renaming this thing to "Settings" is probably ok. Interestingly, quite a few apps seem to use various different terms here - e,g, a quick check here finds: "Options" (Firefox, MS Office), "Preferences" (MuseScore, Inkscape, Audacity), and "Settings" (MS Windows, Vivaldi, Krita (but only as a menu name; the actual entry is called "Configure Krita"))
"Paths" is often something that's very system-dependent AFAIK (e.g. stuff like tempfile directories, editor/viewer paths, etc.), so it probably should go under "SYSTEM"
The "Input" and "Addons" sections you've currently got under "USER PREFERENCES" is probably something that will still be a bit contentious (e.g. what exactly shows up there vs in the workspace specific modes?)
It would be great to make that space/editor/area be made up of multiple regions, instead of just a single one (as now), so that the navigation stuff is always visible. IIRC, we had a proposal once to use a real tab strip, but with this multi-level design.
For the search, it'd be great to have this implemented per user-pref instance, instead of being a semi-global thing. This applies to both the proposed search option, and also the addons search. This is something that has bugged me for a while, especially as it makes it pretty nasty trying to check on the keymaps for properties in several different areas
Another point to note about search is: How are we going to do it? We could just naively filter by property names, but what about things like the labels and layouts that are sometimes needed to make these things work? We can have this discussion later in the process, but it's just something to keep in mind
Perhaps I'm missing/forgetting something here, but how do we intend to handle big equipment-related pen/tablet vs mouse vs mixed configuration things with this UI? Like, where would I expect to go looking for those settings, since this sort of thing could have quite a big impact across the set of keymaps + addons installed (e.g. for a tablet, you might want a bunch of addons for easier access to certain functionality for instance). Is this something that falls under "User Preferences > Input" or "System > General" or do we even need a separate category to deal with this?

In general, I don't have any major objections to the stuff proposed here. Various random points (even though we're still just dealing with rough ideas here atm): * Renaming this thing to "Settings" is probably ok. Interestingly, quite a few apps seem to use various different terms here - e,g, a quick check here finds: "Options" (Firefox, MS Office), "Preferences" (MuseScore, Inkscape, Audacity), and "Settings" (MS Windows, Vivaldi, Krita (but only as a menu name; the actual entry is called "Configure Krita")) * "Paths" is often something that's very system-dependent AFAIK (e.g. stuff like tempfile directories, editor/viewer paths, etc.), so it probably should go under "SYSTEM" * The "Input" and "Addons" sections you've currently got under "USER PREFERENCES" is probably something that will still be a bit contentious (e.g. what exactly shows up there vs in the workspace specific modes?) * It would be great to make that space/editor/area be made up of multiple regions, instead of just a single one (as now), so that the navigation stuff is always visible. IIRC, we had a proposal once to use a real tab strip, but with this multi-level design. * For the search, it'd be great to have this implemented per user-pref instance, instead of being a semi-global thing. This applies to both the proposed search option, and also the addons search. This is something that has bugged me for a while, especially as it makes it pretty nasty trying to check on the keymaps for properties in several different areas * Another point to note about search is: How are we going to do it? We could just naively filter by property names, but what about things like the labels and layouts that are sometimes needed to make these things work? We can have this discussion later in the process, but it's just something to keep in mind * Perhaps I'm missing/forgetting something here, but how do we intend to handle big equipment-related pen/tablet vs mouse vs mixed configuration things with this UI? Like, where would I expect to go looking for those settings, since this sort of thing could have quite a big impact across the set of keymaps + addons installed (e.g. for a tablet, you might want a bunch of addons for easier access to certain functionality for instance). Is this something that falls under "User Preferences > Input" or "System > General" or do we even need a separate category to deal with this?

Julian Eisel commented

2018-02-21 15:44:54 +01:00

In #54115#485326, @JoshuaLeung wrote:

Various random points (even though we're still just dealing with rough ideas here atm):

Renaming this thing to "Settings" is probably ok. Interestingly, quite a few apps seem to use various different terms here - e,g, a quick check here finds: "Options" (Firefox, MS Office), "Preferences" (MuseScore, Inkscape, Audacity), and "Settings" (MS Windows, Vivaldi, Krita (but only as a menu name; the actual entry is called "Configure Krita"))

Yeah... always annoys me that there isn't a standard for this. When dealing with other apps I always search through the menus for an "Options", "Settings" or "Preferences" entry. I bet I'm not the only one. Not sure if I'd catch "User Preferences" if I didn't knew it was called this way.

"Paths" is often something that's very system-dependent AFAIK (e.g. stuff like tempfile directories, editor/viewer paths, etc.), so it probably should go under "SYSTEM"

Indeed, might make sense. For the future, it might also be nice to have a "Security" group for .py script autorun , sandboxing options etc.

The "Input" and "Addons" sections you've currently got under "USER PREFERENCES" is probably something that will still be a bit contentious (e.g. what exactly shows up there vs in the workspace specific modes?)

In my mind the workspace add-ons would be add-on overrides (to override enabled/disabled state and add-on settings). Same with the keymap btw. The mock-up should probably say "Add-on Overrides" in the workspace category.
Note that the groups visible in the mock-up are not meant to be part of the proposal, just some reasonable placeholders to show the point.

It would be great to make that space/editor/area be made up of multiple regions, instead of just a single one (as now), so that the navigation stuff is always visible. IIRC, we had a proposal once to use a real tab strip, but with this multi-level design.

What exactly do you mean with the navigation stuff? The category/group buttons? I actually thought of this as a separate region too (esp. since it might need separate scrolling).

For the search, it'd be great to have this implemented per user-pref instance, instead of being a semi-global thing. This applies to both the proposed search option, and also the addons search. This is something that has bugged me for a while, especially as it makes it pretty nasty trying to check on the keymaps for properties in several different areas

Huh, interesting. Never faced this, but I also only use one UserPref instance usually. Will keep that in mind.
(Testing this, the keymap editor seems to do this just fine.)

Another point to note about search is: How are we going to do it? We could just naively filter by property names, but what about things like the labels and layouts that are sometimes needed to make these things work? We can have this discussion later in the process, but it's just something to keep in mind

Yup, how exactly it's going to work is something we need to look into once basic settings UI design is agreed on. Think the search can be implemented in .py, so we can easily test multiple versions.

Perhaps I'm missing/forgetting something here, but how do we intend to handle big equipment-related pen/tablet vs mouse vs mixed configuration things with this UI? Like, where would I expect to go looking for those settings, since this sort of thing could have quite a big impact across the set of keymaps + addons installed (e.g. for a tablet, you might want a bunch of addons for easier access to certain functionality for instance). Is this something that falls under "User Preferences > Input" or "System > General" or do we even need a separate category to deal with this?

In the mock-up I added a "Devices" group as part of the system settings (also for things like HMDs). That might already work fine. I think it would additionally be wise to split the "Input" tab into "Keyboard" and "Mouse", just for better structuring. If needed we can also add "Pen Tablet", "3D Mouse" and such.
Now, if you want to enable an add-on based on a specific device - shouldn't the add-on handle this somehow? Either in the poll-callback or in its settings. I guess these would be add-ons specifically for a device type (tablet, 3D mouse, ...) anyway.

> In #54115#485326, @JoshuaLeung wrote: > Various random points (even though we're still just dealing with rough ideas here atm): > * Renaming this thing to "Settings" is probably ok. Interestingly, quite a few apps seem to use various different terms here - e,g, a quick check here finds: "Options" (Firefox, MS Office), "Preferences" (MuseScore, Inkscape, Audacity), and "Settings" (MS Windows, Vivaldi, Krita (but only as a menu name; the actual entry is called "Configure Krita")) Yeah... always annoys me that there isn't a standard for this. When dealing with other apps I always search through the menus for an "Options", "Settings" or "Preferences" entry. I bet I'm not the only one. Not sure if I'd catch "User Preferences" if I didn't knew it was called this way. > * "Paths" is often something that's very system-dependent AFAIK (e.g. stuff like tempfile directories, editor/viewer paths, etc.), so it probably should go under "SYSTEM" Indeed, might make sense. For the future, it might also be nice to have a "Security" group for .py script autorun , sandboxing options etc. > * The "Input" and "Addons" sections you've currently got under "USER PREFERENCES" is probably something that will still be a bit contentious (e.g. what exactly shows up there vs in the workspace specific modes?) In my mind the workspace add-ons would be add-on overrides (to override enabled/disabled state and add-on settings). Same with the keymap btw. The mock-up should probably say "Add-on Overrides" in the workspace category. Note that the groups visible in the mock-up are not meant to be part of the proposal, just some reasonable placeholders to show the point. > * It would be great to make that space/editor/area be made up of multiple regions, instead of just a single one (as now), so that the navigation stuff is always visible. IIRC, we had a proposal once to use a real tab strip, but with this multi-level design. What exactly do you mean with the navigation stuff? The category/group buttons? I actually thought of this as a separate region too (esp. since it might need separate scrolling). > * For the search, it'd be great to have this implemented per user-pref instance, instead of being a semi-global thing. This applies to both the proposed search option, and also the addons search. This is something that has bugged me for a while, especially as it makes it pretty nasty trying to check on the keymaps for properties in several different areas Huh, interesting. Never faced this, but I also only use one UserPref instance usually. Will keep that in mind. (Testing this, the keymap editor seems to do this just fine.) > * Another point to note about search is: How are we going to do it? We could just naively filter by property names, but what about things like the labels and layouts that are sometimes needed to make these things work? We can have this discussion later in the process, but it's just something to keep in mind Yup, how exactly it's going to work is something we need to look into once basic settings UI design is agreed on. Think the search can be implemented in .py, so we can easily test multiple versions. > * Perhaps I'm missing/forgetting something here, but how do we intend to handle big equipment-related pen/tablet vs mouse vs mixed configuration things with this UI? Like, where would I expect to go looking for those settings, since this sort of thing could have quite a big impact across the set of keymaps + addons installed (e.g. for a tablet, you might want a bunch of addons for easier access to certain functionality for instance). Is this something that falls under "User Preferences > Input" or "System > General" or do we even need a separate category to deal with this? In the mock-up I added a "Devices" group as part of the system settings (also for things like HMDs). That might already work fine. I think it would additionally be wise to split the "Input" tab into "Keyboard" and "Mouse", just for better structuring. If needed we can also add "Pen Tablet", "3D Mouse" and such. Now, if you want to enable an add-on based on a specific device - shouldn't the add-on handle this somehow? Either in the poll-callback or in its settings. I guess these would be add-ons specifically for a device type (tablet, 3D mouse, ...) anyway.

Vuk Gardašević commented

2018-02-21 17:35:56 +01:00

Added subscriber: @VukGardasevic

Vuk Gardašević commented

2018-02-21 17:35:56 +01:00

Implementing a data independent scrollable box (scroll_box or similar) would be a good start. UI list are a bit difficult to use as they need data defined first and a counter for tracking the active state.
Having a box widget that makes all UI children entries being accessible with scrollbars (vertically and horizontally) could help a lot with organization and saving space. Behaving like a region in a box. :)

Implementing a data independent scrollable box (scroll_box or similar) would be a good start. UI list are a bit difficult to use as they need data defined first and a counter for tracking the active state. Having a box widget that makes all UI children entries being accessible with scrollbars (vertically and horizontally) could help a lot with organization and saving space. Behaving like a region in a box. :)

Pierre Schiller commented

2018-02-21 23:18:31 +01:00

Added subscriber: @PierreSchiller

Pierre Schiller commented

2018-02-21 23:18:31 +01:00

Could this be a good time to propose a NEW SPLASH screen? to better simplify the first user enounter with the software?

Joshua Leung commented

2018-02-22 04:01:19 +01:00

@JulianEisel Right. That sounds reasonable.

What exactly do you mean with the navigation stuff? The category/group buttons?

Yep, that sidebar :)

I think it would additionally be wise to split the "Input" tab into "Keyboard" and "Mouse"

Hmm... I'm not so sure that it really makes sense to do that - at least not right now. Maybe for global settings like rotate/scrollwheel behaviour vs general hotkeys it might be ok, but I have doubts about whether it'd really be beneficial splitting out stuff like Selection Operators/3D Cursor/GPencil etc. actions on mouse clicks from hotkey invoked stuff. Especially since it's possible to still create conflicts by setting a normal key as a modifier for a mouse-action when that same key may be used elsewhere.

@VukGardasevic You're basically just describing the "View2D" system :P While we haven't actually tested using one View2D nested inside another one (i.e. they are currently only inline-attached to all ARegions), IIRC, there isn't actually stopping you from being able to use one like that. On that note, maybe I need to give this a go ;)

@PierreSchiller That's a separate issue. I'm not sure if it's currently on our todolist or not

@JulianEisel Right. That sounds reasonable. > What exactly do you mean with the navigation stuff? The category/group buttons? Yep, that sidebar :) > I think it would additionally be wise to split the "Input" tab into "Keyboard" and "Mouse" Hmm... I'm not so sure that it really makes sense to do that - at least not right now. Maybe for global settings like rotate/scrollwheel behaviour vs general hotkeys it might be ok, but I have doubts about whether it'd really be beneficial splitting out stuff like Selection Operators/3D Cursor/GPencil etc. actions on mouse clicks from hotkey invoked stuff. Especially since it's possible to still create conflicts by setting a normal key as a modifier for a mouse-action when that same key may be used elsewhere. @VukGardasevic You're basically just describing the "View2D" system :P While we haven't actually tested using one View2D nested inside another one (i.e. they are currently only inline-attached to all ARegions), IIRC, there isn't actually stopping you from being able to use one like that. On that note, maybe I need to give this a go ;) @PierreSchiller That's a separate issue. I'm not sure if it's currently on our todolist or not

Brecht Van Lommel commented

2018-02-22 04:43:24 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2018-02-22 04:43:24 +01:00

This generally seems fine to me. I think the breadcrumbs at the top are unnecessary, it doesn't look like the nesting would need to be very deep.

If you go ahead with this, I suggest to implement it incrementally into blender2.8, don't make a big branch where you try to do everything. But rather finish it step by step, for example:

Create two regions with navigations tabs on the left.
Start breaking up categories and reorganizing buttons into them.
Add two levels of navigation.
Make category widgets look nicer.
Improve button layouts for each category.
Implement search.

This generally seems fine to me. I think the breadcrumbs at the top are unnecessary, it doesn't look like the nesting would need to be very deep. If you go ahead with this, I suggest to implement it incrementally into blender2.8, don't make a big branch where you try to do everything. But rather finish it step by step, for example: * Create two regions with navigations tabs on the left. * Start breaking up categories and reorganizing buttons into them. * Add two levels of navigation. * Make category widgets look nicer. * Improve button layouts for each category. * Implement search.

Julian Eisel commented

2018-02-22 10:15:31 +01:00

In #54115#485386, @PierreSchiller wrote:
Could this be a good time to propose a NEW SPLASH screen? to better simplify the first user enounter with the software?

I'd love to see work on this (in fact, I already did some research), however I'm afraid it's much more complicated than this settings UI redesign. For example the new splash screen should contain a quick setup for special devices (3D mice, pen tablets, multi-touch screens, etc), we don't really know how to integrate such settings nicely yet. There are quite a few loose ends like this.

I'm familiar with what you proposed in other discussions, it's definitely a good start. I'd propose to make it a multi-page splash screen though, see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Splash_Screen.

You're more than welcome to create a proposal, just saying that this task is more tangible and that I'd like to focus on it first.

In #54115#485408, @JoshuaLeung wrote:

I think it would additionally be wise to split the "Input" tab into "Keyboard" and "Mouse"

Hmm... I'm not so sure that it really makes sense to do that - at least not right now. Maybe for global settings like rotate/scrollwheel behaviour vs general hotkeys it might be ok, but I have doubts about whether it'd really be beneficial splitting out stuff like Selection Operators/3D Cursor/GPencil etc. actions on mouse clicks from hotkey invoked stuff. Especially since it's possible to still create conflicts by setting a normal key as a modifier for a mouse-action when that same key may be used elsewhere.

Correction: There should definitely still be a group for the keymap-editing, maybe call it "Shortcuts/Key-map" or so. What I wanted to say is that we should have one group just for keymap-editing, and separate groups for device specific options. That way we can keep the individual groups uncluttered & rather focused.

In #54115#485441, @brecht wrote:
This generally seems fine to me. I think the breadcrumbs at the top are unnecessary, it doesn't look like the nesting would need to be very deep.

Think this is useful when the navigation region is hidden, or as a general hint. But indeed, it's a bit redundant.

If you go ahead with this, I suggest to implement it incrementally into blender2.8, don't make a big branch where you try to do everything.

Definitely +1. Actually wanted to do something like this, what I said about creating a prototype first may have been a bit misleading.

> In #54115#485386, @PierreSchiller wrote: > Could this be a good time to propose a NEW SPLASH screen? to better simplify the first user enounter with the software? I'd love to see work on this (in fact, I already did some research), however I'm afraid it's much more complicated than this settings UI redesign. For example the new splash screen should contain a quick setup for special devices (3D mice, pen tablets, multi-touch screens, etc), we don't really know how to integrate such settings nicely yet. There are quite a few loose ends like this. I'm familiar with what you proposed in other discussions, it's definitely a good start. I'd propose to make it a multi-page splash screen though, see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Splash_Screen. You're more than welcome to create a proposal, just saying that this task is more tangible and that I'd like to focus on it first. ---- > In #54115#485408, @JoshuaLeung wrote: >> I think it would additionally be wise to split the "Input" tab into "Keyboard" and "Mouse" > Hmm... I'm not so sure that it really makes sense to do that - at least not right now. Maybe for global settings like rotate/scrollwheel behaviour vs general hotkeys it might be ok, but I have doubts about whether it'd really be beneficial splitting out stuff like Selection Operators/3D Cursor/GPencil etc. actions on mouse clicks from hotkey invoked stuff. Especially since it's possible to still create conflicts by setting a normal key as a modifier for a mouse-action when that same key may be used elsewhere. Correction: There should definitely still be a group for the keymap-editing, maybe call it "Shortcuts/Key-map" or so. What I wanted to say is that we should have one group just for keymap-editing, and separate groups for device specific options. That way we can keep the individual groups uncluttered & rather focused. ---- > In #54115#485441, @brecht wrote: > This generally seems fine to me. I think the breadcrumbs at the top are unnecessary, it doesn't look like the nesting would need to be very deep. Think this is useful when the navigation region is hidden, or as a general hint. But indeed, it's a bit redundant. > If you go ahead with this, I suggest to implement it incrementally into blender2.8, don't make a big branch where you try to do everything. Definitely +1. Actually wanted to do something like this, what I said about creating a prototype first may have been a bit misleading.

Julian Eisel commented

2018-02-22 10:27:16 +01:00

I think I'll actually go ahead and start working on this in the blender2.8 branch, just like @brecht suggested. There don't seem to be any bigger objections against the proposed changes :)

Brecht Van Lommel commented

2018-02-22 16:52:09 +01:00

To be clear, by working directly in blender2.8 I meant committing safe/simpler changes directly and more complicated ones can still go through code review. I rather not have more half-finished stuff in blender2.8, but if each individual step is committed in a finished state that's fine.

Vuk Gardašević commented

2018-02-22 17:22:43 +01:00

In #54115#485408, @JoshuaLeung wrote:

You're basically just describing the "View2D" system :P While we haven't actually tested using one View2D nested inside another one (i.e. they are currently only inline-attached to all ARegions), IIRC, there isn't actually stopping you from being able to use one like that. On that note, maybe I need to give this a go ;)

Yes, that would be really helpful:)

> In #54115#485408, @JoshuaLeung wrote: >You're basically just describing the "View2D" system :P While we haven't actually tested using one View2D nested inside another one (i.e. they are currently only inline-attached to all ARegions), IIRC, there isn't actually stopping you from being able to use one like that. On that note, maybe I need to give this a go ;) Yes, that would be really helpful:)

Pablo Vazquez commented

2018-02-26 12:19:50 +01:00

Added subscriber: @pablovazquez

Pablo Vazquez commented

2018-02-26 12:19:50 +01:00

Awesome! Sorry I didn't have time to look into this before, was busy with the Code Quest.

I agree with pretty much everything mentioned here. I would even add to the "Outdated/aging design" rationale that the current design is legacy from Blender 2.27! (2.26 and previous all settings were together in a flat layout). A quick look just for history purposes:

To sum up:

User Preferences -> Settings
Sidebar with independent scroll
Sidebar sections split in categories

For categories that have many subcategories, we can (in the future) look into nested sidebar navigation. See "Devices" in the video below.

Most settings could be ported as-is for the time being. And later re-design those that already have a sidebar + search, like add-ons.

This is how the current GNOME settings look like, much better than the previous approach:
vid_6523-2018-02-26_12.07.54.mp4

Still has issues though:

Settings should be sorted from general to specific.
** The first item on the list here is WiFi, which on a Desktop computer usually is off, showing the "?" icon makes it look like there's something wrong.
Title of the section (like "Devices") could go back to the Devices list, not a problem if we have breadcrumbs
When searching, GNOME shows the WiFi settings (first item on the settings list), it should show the content of the first/most relevant search result

Pretty excited about this! And can't wait to work on the simplified theme settings :)
Thanks @JulianEisel !

Awesome! Sorry I didn't have time to look into this before, was busy with the Code Quest. I agree with pretty much everything mentioned here. I would even add to the "Outdated/aging design" rationale that the current design is legacy from Blender 2.27! (2.26 and previous all settings were together in a flat layout). A quick look just for history purposes: ![Screenshot from 2018-02-26 11-41-49.png](https://archive.blender.org/developer/F2370268/Screenshot_from_2018-02-26_11-41-49.png) To sum up: * User Preferences -> Settings * Sidebar with independent scroll * Sidebar sections split in categories For categories that have many subcategories, we can (in the future) look into nested sidebar navigation. See "Devices" in the video below. Most settings could be ported as-is for the time being. And later re-design those that already have a sidebar + search, like add-ons. This is how the current GNOME settings look like, much better than the previous approach: [vid_6523-2018-02-26_12.07.54.mp4](https://archive.blender.org/developer/F2370364/vid_6523-2018-02-26_12.07.54.mp4) Still has issues though: * Settings should be sorted from general to specific. ** The first item on the list here is WiFi, which on a Desktop computer usually is off, showing the "?" icon makes it look like there's something wrong. * Title of the section (like "Devices") could go back to the Devices list, not a problem if we have breadcrumbs * When searching, GNOME shows the WiFi settings (first item on the settings list), it should show the content of the first/most relevant search result Pretty excited about this! And can't wait to work on the simplified theme settings :) Thanks @JulianEisel !

michael knubben commented

2018-05-04 11:38:51 +02:00

Added subscriber: @michaelknubben

Matias Mendiola commented

2018-05-30 13:58:48 +02:00

Added subscriber: @mendio

Gibran Kaleel commented

2018-08-24 10:23:51 +02:00

Added subscriber: @JonDoe286

Julien Kaspar commented

2018-09-18 00:17:57 +02:00

Added subscriber: @JulienKaspar

Brecht Van Lommel changed title from ~~Redesign User Preferences for 2.8x~~ to Redesign User Preferences

2018-09-28 16:45:48 +02:00

KiJeon commented

2018-11-10 12:14:48 +01:00

Added subscriber: @0o00o0oo

William Reynish commented

2018-11-25 18:31:14 +01:00

Added subscriber: @WilliamReynish

William Reynish commented

2018-11-25 18:31:14 +01:00

UI tweak:

Change name to Preferences
Added proper panels
Preferences works better like this when narrower
Search
Save Preferences moved to the side

{F5716371, size=full}

UI tweak: - Change name to Preferences - Added proper panels - Preferences works better like this when narrower - Search - Save Preferences moved to the side {[F5716371](https://archive.blender.org/developer/F5716371/Screenshot_2018-11-25_at_18.41.29.png), size=full}

William Reynish commented

2018-11-25 19:11:26 +01:00

We could make use of panels more places in Preferences, such as Themes, for example: {F5716572, size=full}

We could make use of panels more places in Preferences, such as Themes, for example: {[F5716572](https://archive.blender.org/developer/F5716572/Screenshot_2018-11-25_at_19.10.49.png), size=full}

Julian Eisel commented

2018-11-26 01:14:02 +01:00

Made a (rough) implementation of the panel based layout for testing, which looks like this:

Patch for testing (Python only): P834

Made a (rough) implementation of the panel based layout for testing, which looks like this: ![settings_new_alignment.png](https://archive.blender.org/developer/F5719266/settings_new_alignment.png) Patch for testing (Python only): [P834](https://archive.blender.org/developer/P834.txt)

William Reynish commented

2018-11-26 11:29:52 +01:00

@JulianEisel Nice one. We could even add sub-panels here too, for things like the New F-Curve Defaults under Keyframing. This could be used to great effect many places.

As a test, I modified your Python file to do this:

@JulianEisel Nice one. We could even add sub-panels here too, for things like the New F-Curve Defaults under Keyframing. This could be used to great effect many places. As a test, I modified your Python file to do this: ![Screenshot 2018-11-26 at 11.57.58.png](https://archive.blender.org/developer/F5724401/Screenshot_2018-11-26_at_11.57.58.png)

Julian Eisel commented

2018-11-26 15:24:55 +01:00

@WilliamReynish suggested to go with the term "Preferences" rather than "Settings":

In b00963afc1#206251, @WilliamReynish wrote:
Hey, this is a nice improvement already. The only thing I would opine against is the name. 'Settings' is much more ambiguous than 'Preferences', especially in an app like Blender which includes many settings in the Properties Editor and lots of other places.

The name 'Preferences' serves as a much more unambiguous differentiation from other settings, than the name 'Settings'. Plus, Preferences is a general standard name for this kind of thing.

I agree with him, he makes a good point. So if nobody objects I'll change the term.

@WilliamReynish suggested to go with the term "Preferences" rather than "Settings": > In b00963afc1#206251, @WilliamReynish wrote: > Hey, this is a nice improvement already. The only thing I would opine against is the name. 'Settings' is much more ambiguous than 'Preferences', especially in an app like Blender which includes many settings in the Properties Editor and lots of other places. > > The name 'Preferences' serves as a much more unambiguous differentiation from other settings, than the name 'Settings'. Plus, Preferences is a general standard name for this kind of thing. I agree with him, he makes a good point. So if nobody objects I'll change the term.

Brecht Van Lommel commented

2018-11-26 15:29:59 +01:00

Agreed, let's change it to Preferences.

blender-admin commented

2018-11-28 12:21:49 +01:00

This issue was referenced by dac747bd09

This issue was referenced by dac747bd095260bf72570f9226e3cd1e7eb9b991

William Reynish commented

2018-12-04 20:39:53 +01:00

Here's a patch to add panels to all the areas of Preferences.

*Adds panels to Interface, Editing, Input, General and Files sections
*Split apart Input from keymap
*fixes the issue with the UI Scale widget glitching
*A few small tweaks

UserPreferences_panels.diff

Looks like this:

Here's a patch to add panels to all the areas of Preferences. *Adds panels to Interface, Editing, Input, General and Files sections *Split apart Input from keymap *fixes the issue with the UI Scale widget glitching *A few small tweaks [UserPreferences_panels.diff](https://archive.blender.org/developer/F5818282/UserPreferences_panels.diff) Looks like this: ![Screenshot 2018-12-03 at 22.35.22.png](https://archive.blender.org/developer/F5818304/Screenshot_2018-12-03_at_22.35.22.png) ![Screenshot 2018-12-03 at 22.35.29.png](https://archive.blender.org/developer/F5818309/Screenshot_2018-12-03_at_22.35.29.png) ![Screenshot 2018-12-03 at 22.34.51.png](https://archive.blender.org/developer/F5818314/Screenshot_2018-12-03_at_22.34.51.png) ![Screenshot 2018-12-03 at 22.35.03.png](https://archive.blender.org/developer/F5818322/Screenshot_2018-12-03_at_22.35.03.png) ![Screenshot 2018-12-03 at 22.35.08.png](https://archive.blender.org/developer/F5818329/Screenshot_2018-12-03_at_22.35.08.png)

Brecht Van Lommel commented

2018-12-05 17:11:01 +01:00

This looks great. @JulianEisel, I guess you can commit this to your branch and help reviewing it?

I think we should only commit this when it's in a finished state, since moving around items multiple times is annoying for users.

Some feedback from a quick test.

Python errors:

Traceback (most recent call last):
  File "/home/brecht/dev/build_linux/bin/2.80/scripts/startup/bl_ui/space_userpref.py", line 668, in poll
    return (userpref.active_section == 'SYSTEM_GENERAL')
NameError: name 'userpref' is not defined

Under Interface I think there should be a separate 3D Viewport panel, UI Scale, Line Width, Tooltips do not belong together with them.
For addons some buttons are duplicated at the top and in the header. IMO a button like "Install Addon" should bigger and have text, not be just a "+". The search box also deserves to be bigger.
Text and weight paint range options from System > General should probably move to Interface. OpenGL > Text options belong in the top level Text panel I think, these are about how users want things to look.
Region Overlap could move to Interface.
Cycles Compute Device panel has "Cycles Compute Device" twice.

This looks great. @JulianEisel, I guess you can commit this to your branch and help reviewing it? I think we should only commit this when it's in a finished state, since moving around items multiple times is annoying for users. Some feedback from a quick test. * Python errors: ``` Traceback (most recent call last): File "/home/brecht/dev/build_linux/bin/2.80/scripts/startup/bl_ui/space_userpref.py", line 668, in poll return (userpref.active_section == 'SYSTEM_GENERAL') NameError: name 'userpref' is not defined ``` * Under Interface I think there should be a separate 3D Viewport panel, UI Scale, Line Width, Tooltips do not belong together with them. * For addons some buttons are duplicated at the top and in the header. IMO a button like "Install Addon" should bigger and have text, not be just a "+". The search box also deserves to be bigger. * Text and weight paint range options from System > General should probably move to Interface. OpenGL > Text options belong in the top level Text panel I think, these are about how users want things to look. * Region Overlap could move to Interface. * Cycles Compute Device panel has "Cycles Compute Device" twice.

William Reynish commented

2018-12-06 01:04:22 +01:00

@brecht Agreed on all points.

Re. the header, it was a bit of an experiment. We need to define the role of the header here. Currently, the placement of the Editor type selector is clumsy in the middle, and it’s also weird that it defaults to being on the bottom.

We could either hide the header and move everything into the panels, or maybe put the header at the top, and make it span the entire width to put the Editor type selector at the far left. Although it will still be mostly empty then. That was why I thought to try and move everything out of the header, so that we could simply hide it by default.

@brecht Agreed on all points. Re. the header, it was a bit of an experiment. We need to define the role of the header here. Currently, the placement of the Editor type selector is clumsy in the middle, and it’s also weird that it defaults to being on the bottom. We could either hide the header and move everything into the panels, or maybe put the header at the top, and make it span the entire width to put the Editor type selector at the far left. Although it will still be mostly empty then. That was why I thought to try and move everything out of the header, so that we could simply hide it by default.

Julian Eisel commented

2018-12-17 00:38:14 +01:00

@WilliamReynish and I continued work in the userpref_redesign branch. Mostly working on the panel/subpanel based layout.
Current screenshots:

@WilliamReynish and I continued work in the `userpref_redesign` branch. Mostly working on the panel/subpanel based layout. Current screenshots: ![new_settings_input_.png](https://archive.blender.org/developer/F5975226/new_settings_input_.png) ![new_settings_themes_1_.png](https://archive.blender.org/developer/F5975229/new_settings_themes_1_.png) ![new_settings_themes_2_.png](https://archive.blender.org/developer/F5975231/new_settings_themes_2_.png)

William Reynish commented

2018-12-18 21:11:58 +01:00

Hi @JulianEisel,

I've done some additional layout work on the Preferences from your branch.

Header is now fully redundant. Added buttons to add studio lights under the Lights category.
Removed redundant theme category dropdown
Made the theme layout use layout flow, so it goes to single column when narrow, but multiple columns as you make it wider
Made all the themes layouts consistent and all use property split fit with the rest of 2.8
Fix UI Scale property so it doesn't flicker, by making it a number value rather than a slider - it's more correct this way anyway

Some screenies:

Narrow:

Wide:

Other examples of consistent 2.8-style layout:

Patch:
Preferences_layout_update.diff

From here, we should also make four other smaller changes, which I'm not immediately sure how to do;

Make Preferences less wide by default
I think we should remove the colons next to User and System (tried to remove but couldn't find where this was set)
Anchor the Save Preferences button to be at the bottom of the window
Hide header by default when opened as a window

With these four changes I would say this is good enough to merge into 2.8.

Hi @JulianEisel, I've done some additional layout work on the Preferences from your branch. - Header is now fully redundant. Added buttons to add studio lights under the Lights category. - Removed redundant theme category dropdown - Made the theme layout use layout flow, so it goes to single column when narrow, but multiple columns as you make it wider - Made all the themes layouts consistent and all use property split fit with the rest of 2.8 - Fix UI Scale property so it doesn't flicker, by making it a number value rather than a slider - it's more correct this way anyway Some screenies: Narrow: ![Screenshot 2018-12-18 at 21.16.54.png](https://archive.blender.org/developer/F5996384/Screenshot_2018-12-18_at_21.16.54.png) Wide: ![Screenshot 2018-12-18 at 21.17.18.png](https://archive.blender.org/developer/F5996388/Screenshot_2018-12-18_at_21.17.18.png) Other examples of consistent 2.8-style layout: ![Screenshot 2018-12-18 at 21.08.16.png](https://archive.blender.org/developer/F5996231/Screenshot_2018-12-18_at_21.08.16.png) Patch: [Preferences_layout_update.diff](https://archive.blender.org/developer/F5996438/Preferences_layout_update.diff) From here, we should also make four other smaller changes, which I'm not immediately sure how to do; - Make Preferences less wide by default - I think we should remove the colons next to User and System (tried to remove but couldn't find where this was set) - Anchor the Save Preferences button to be at the bottom of the window - Hide header by default when opened as a window With these four changes I would say this is good enough to merge into 2.8.

Duarte Farrajota Ramos commented

2018-12-19 01:29:54 +01:00

Looking pretty good so far, huge improvement. Only one small nitpicking.
The save button is perfectly aligned with the preference categories tabs, and is exactly the same size and style. It looks way too much like one of them despite being a completely different type of UI element.
This might be potentially dangerous for the user accidentally saving changes instead of switching tabs.

Perhaps always aligning it to the bottom of the window and adding some sort of save icon in it (like Install and Reset in the header) would suffice. A slightly different color or size could also help.

Would it be possible to remember preference window size when saving startup file? It is generally too small by default on large monitors, and it gets bothersome to resize it every time.

Looking pretty good so far, huge improvement. Only one small nitpicking. The save button is perfectly aligned with the preference categories tabs, and is exactly the same size and style. It looks way too much like one of them despite being a completely different type of UI element. This might be potentially dangerous for the user accidentally saving changes instead of switching tabs. Perhaps always aligning it to the bottom of the window and adding some sort of save icon in it (like *Install* and *Reset* in the header) would suffice. A slightly different color or size could also help. Would it be possible to remember preference window size when saving startup file? It is generally too small by default on large monitors, and it gets bothersome to resize it every time.

William Reynish commented

2018-12-19 15:10:06 +01:00

@DuarteRamos: Yes, for sure. It needs to be anchored to the bottom. It's just technically a bit harder to do, so I will leave that for @JulianEisel

William Reynish commented

2018-12-20 09:56:24 +01:00

@JulianEisel: Another small patch for Preferences against your latest updates in the branch:

Fixed gap in Viewports panel
Made all buttons to install things (Addons, Lights, Keymaps, Themes etc) use the same icon and use elipses (...) to communicate the fact that they open a dialog.
Fixed own code error in Input > View panel
Re-ordered panels in Input section - now related Mouse and Devices panels are next to each other
Renamed User Preferences in the Editor list to just Preferences - consistent with Edit > Preferences
Removed icon for auto-key toggle - doesn't fit here

Patch:
Preferences_layout_update2.diff

@JulianEisel: Another small patch for Preferences against your latest updates in the branch: - Fixed gap in Viewports panel - Made all buttons to install things (Addons, Lights, Keymaps, Themes etc) use the same icon and use elipses (...) to communicate the fact that they open a dialog. - Fixed own code error in Input > View panel - Re-ordered panels in Input section - now related Mouse and Devices panels are next to each other - Renamed User Preferences in the Editor list to just Preferences - consistent with Edit > Preferences - Removed icon for auto-key toggle - doesn't fit here Patch: [Preferences_layout_update2.diff](https://archive.blender.org/developer/F6014244/Preferences_layout_update2.diff)

William Reynish commented

2018-12-22 11:32:43 +01:00

Another update to Preferences, against the latest preferences_redesign branch:

1: There was a theme conflict here where the side panel and the panel are the same color. I made the side panel brighter to fix this - it also has the benefit of communicating the higher place in the hierarchy.

Before:

After:

2: Further cleaning up of Input section. Before, the Mouse panel was outside the Devices panel. Now all device input settings are grouped together. (Mouse and Keyboard are expended by default)

3: There were two View manipulation panels: One in Interface section and another in the Input section. This has been the case since 2.5. But actually, these sections contain the exact same category of options. It made no sense that half of these options were in different sections. I have now consolidated these options and categorised them logically in Orbit, Zoom, Cursor and Fly/Walk - all under Input:

I also made the required re-org in RNA to match this.

4: The Save Preferences button.

While I still think anchoring it to the bottom of the side panel is neat, I also don’t particularly mind putting it in the header, aligned to the right. @JulianEisel If you want, you are still welcome to do it the other way, but if it’s too much work, this can work too I think:

It’s actually similar to your original proposal for it, and it has the nice benefit that it separates it more from the sections in the side panel. The downside is that then the header needs to be visible, which reveals the editor dropdown menu.

What do you think we should do here?

Patch:

Preferences_Layout_4.diff

PS: Another idea might be to move the Text section from System to Interface. Seems to make more sense as an Interface option to me. @JulianEisel @brecht Thoughts?

Another update to Preferences, against the latest preferences_redesign branch: 1: There was a theme conflict here where the side panel and the panel are the same color. I made the side panel brighter to fix this - it also has the benefit of communicating the higher place in the hierarchy. Before: ![Screenshot 2018-12-21 at 13.47.50.png](https://archive.blender.org/developer/F6033755/Screenshot_2018-12-21_at_13.47.50.png) After: ![Screenshot 2018-12-22 at 11.46.44.png](https://archive.blender.org/developer/F6033910/Screenshot_2018-12-22_at_11.46.44.png) 2: Further cleaning up of Input section. Before, the Mouse panel was outside the Devices panel. Now all device input settings are grouped together. (Mouse and Keyboard are expended by default) ![Screenshot 2018-12-22 at 11.31.04.png](https://archive.blender.org/developer/F6033805/Screenshot_2018-12-22_at_11.31.04.png) 3: There were two View manipulation panels: One in Interface section and another in the Input section. This has been the case since 2.5. But actually, these sections contain the exact same category of options. It made no sense that half of these options were in different sections. I have now consolidated these options and categorised them logically in Orbit, Zoom, Cursor and Fly/Walk - all under Input: ![Screenshot 2018-12-22 at 11.27.54.png](https://archive.blender.org/developer/F6033784/Screenshot_2018-12-22_at_11.27.54.png) I also made the required re-org in RNA to match this. 4: The Save Preferences button. While I still think anchoring it to the bottom of the side panel is neat, I also don’t particularly mind putting it in the header, aligned to the right. @JulianEisel If you want, you are still welcome to do it the other way, but if it’s too much work, this can work too I think: ![Screenshot 2018-12-21 at 20.31.50.png](https://archive.blender.org/developer/F6033766/Screenshot_2018-12-21_at_20.31.50.png) It’s actually similar to your original proposal for it, and it has the nice benefit that it separates it more from the sections in the side panel. The downside is that then the header needs to be visible, which reveals the editor dropdown menu. What do you think we should do here? Patch: [Preferences_Layout_4.diff](https://archive.blender.org/developer/F6033802/Preferences_Layout_4.diff) PS: Another idea might be to move the Text section from System to Interface. Seems to make more sense as an Interface option to me. @JulianEisel @brecht Thoughts?

Julian Eisel commented

2018-12-23 10:32:15 +01:00

Your changes seem reasonable. I'll push them in a minute.

Regarding the save preferences button, I already started working on the separate region for it, it's not a big deal really. To differentiate the button from the navigation buttons, we could shade the background color slightly different, and/or make the button use a different size.
Regarding the text options: I agree these should be put into the Interface section. I think they used to be there to workaround issues on old graphics cards/drivers, that's changed now.

Some more thoughts as we get to a more final stage:

The way we center layouts in the panels could use some work. As space gets more narrow, left and right margins around the layout should be reduced too. Otherwise the layout just doesn't work well when used as a regular editor (not in the temporary window).
For installing Add-ons, a file browser is opened in the temporary window. We already had space issues here, with the decreased window width it's worse. We might want to think about better ways to handle this.

Your changes seem reasonable. I'll push them in a minute. Regarding the save preferences button, I already started working on the separate region for it, it's not a big deal really. To differentiate the button from the navigation buttons, we could shade the background color slightly different, and/or make the button use a different size. Regarding the text options: I agree these should be put into the Interface section. I think they used to be there to workaround issues on old graphics cards/drivers, that's changed now. Some more thoughts as we get to a more final stage: * The way we center layouts in the panels could use some work. As space gets more narrow, left and right margins around the layout should be reduced too. Otherwise the layout just doesn't work well when used as a regular editor (not in the temporary window). * For installing Add-ons, a file browser is opened in the temporary window. We already had space issues here, with the decreased window width it's worse. We might want to think about better ways to handle this.

William Reynish commented

2018-12-23 11:39:02 +01:00

@JulianEisel: Great. Yes, the margins could be smarter. If the window is narrow, they could become smaller or disappear completely.

The addons file browser thing doesn't seem so bad to me. In the default size I see this:

In general though, the file browser in Blender could be made to open as a new temporary window by default. That would eliminate the need for the clumsy Back to Previous button, and it makes it much simpler to go back. Resizing the file browser then doesn't affect the Blender window it was spawned from.

But I see that as more of a general problem with the file browser than an issue that is specific to the addons.

@JulianEisel: Great. Yes, the margins could be smarter. If the window is narrow, they could become smaller or disappear completely. The addons file browser thing doesn't seem so bad to me. In the default size I see this: ![Screenshot 2018-12-23 at 11.36.19.png](https://archive.blender.org/developer/F6043871/Screenshot_2018-12-23_at_11.36.19.png) In general though, the file browser in Blender could be made to open as a new temporary window by default. That would eliminate the need for the clumsy Back to Previous button, and it makes it much simpler to go back. Resizing the file browser then doesn't affect the Blender window it was spawned from. But I see that as more of a general problem with the file browser than an issue that is specific to the addons.

William Reynish commented

2018-12-24 14:24:45 +01:00

Latest update is nice. I've made a few more tweaks here:

Removed doubled Cycles Compute Device text
Moved header placement into menus panel
Moved Text panel & rna to Interface
Moved OpenGL Texture panel inside OpenGL panel
Moved Color Picker Type to from System>Misc to Interface>Menus (eventually it'd be nice to include this option inside the color pickers themselves to make it more useful and discoverable)
Combined all memory-related preferences (Undo + Console Scrollback + Sequencer Cache) in a Memory panel in System section (avoids needing previous Misc panel)
Added correct greying out to Files > Auto Run Python Scripts panel
Added flow layout to Save & Load checkboxes
Rejiggered some of the Texture preferences to make more logical sense together
A few other minor adjustments

(updated Dec 27 '18)

Preferences_Layout_5.diff

Latest update is nice. I've made a few more tweaks here: - Removed doubled Cycles Compute Device text - Moved header placement into menus panel - Moved Text panel & rna to Interface - Moved OpenGL Texture panel inside OpenGL panel - Moved Color Picker Type to from System>Misc to Interface>Menus (eventually it'd be nice to include this option inside the color pickers themselves to make it more useful and discoverable) - Combined all memory-related preferences (Undo + Console Scrollback + Sequencer Cache) in a Memory panel in System section (avoids needing previous Misc panel) - Added correct greying out to Files > Auto Run Python Scripts panel - Added flow layout to Save & Load checkboxes - Rejiggered some of the Texture preferences to make more logical sense together - A few other minor adjustments (updated Dec 27 '18) [Preferences_Layout_5.diff](https://archive.blender.org/developer/F6088227/Preferences_Layout_5.diff)

William Reynish commented

2018-12-27 18:43:48 +01:00

Another thing that may be interesting eventually, is to improve the keymap editor with a keyboard-centric view to get an overview of which keys are bound to which commands. This gives a better overview than a simple list of commands.

You could then click on a key and assign a command. Something like this:

Another thing that may be interesting eventually, is to improve the keymap editor with a keyboard-centric view to get an overview of which keys are bound to which commands. This gives a better overview than a simple list of commands. You could then click on a key and assign a command. Something like this: ![Screenshot 2018-12-27 at 13.11.58.png](https://archive.blender.org/developer/F6088257/Screenshot_2018-12-27_at_13.11.58.png)

Loïc DAUTRY commented

2018-12-29 11:46:12 +01:00

Added subscriber: @L0Lock

Loïc DAUTRY commented

2018-12-29 11:46:12 +01:00

@WilliamReynish Would it be possible to make this keyboard-centric view automatically adapt to the user's keyboard layout (or at least the main qwerty and azerty)?

Julian Eisel commented

2019-01-04 23:27:43 +01:00

Changed status from 'Open' to: 'Resolved'

Julian Eisel closed this issue

2019-01-04 23:27:43 +01:00

Julian Eisel self-assigned this 2019-01-04 23:27:43 +01:00

Julian Eisel commented

2019-01-04 23:27:43 +01:00

I've just committed a77b63c569 with which I'd consider the Preferences redesign as done.
From this task I think the only thing missing is the search, which can be added as general improvement. @WilliamReynish and I already planned to work on the workspace preferences UI next, but that will probably get its own task.

A note on theme settings: I'm well aware that the re-organized theme settings don't solve the underlying issue of overwhelming complexity. Much more drastic changes are needed for this. I'm personally trying to address this as part of my bWidgets project, which I hope to push quite a bit in 2019.

Closing this task, thanks everybody for the involvement!

I've just committed a77b63c569 with which I'd consider the Preferences redesign as done. From this task I think the only thing missing is the search, which can be added as general improvement. @WilliamReynish and I already planned to work on the workspace preferences UI next, but that will probably get its own task. A note on theme settings: I'm well aware that the re-organized theme settings don't solve the underlying issue of overwhelming complexity. Much more drastic changes are needed for this. I'm personally trying to address this as part of my [bWidgets ](https://julianeisel.github.io/bWidgets/) project, which I hope to push quite a bit in 2019. Closing this task, thanks everybody for the involvement!

Sign in to join this conversation.