Page MenuHome

UI: Preferences Redesign Part 2
ClosedPublic

Authored by Julian Eisel (Severin) on Sun, Dec 30, 6:05 PM.

Details

Summary

UI: Preferences Redesign Part 2

Design task: T54115

Does the following changes visible to users:

  • Use panels and sub-panels to group elements in a more structured and logical way
  • Re-organized options more logically than before (see images below)
  • Use flow layout (single column by default).
  • New layout uses horizontal margin if there's enough space.
  • General reordering and renaming of buttons/panels/etc & icon changes.
  • Move keymap related options from "Input" into own section.
  • Own, left-bottom aligned region for Save Preferences button.
  • Decrease width of Preferences window to suit new layout.
  • Move buttons from header into the main region (except editor switch).
  • Hide Preferences header when opened in temporary window.
  • Don't use slider but regular number widget for UI scale.
  • Use full area width for header.

Internal changes:

  • Rearrange RNA properties to match changed UI structure.
  • Introduces new "EXECUTE" region type, see reasoning in D3982.
  • Changes to panel layout and AZone code for dynamic panel region.
  • Bumps subversion and does versioning for new regions.

A detailed list of changed RNA paths should be (and rearranged UI
items?) done for the release notes.

Patch by @William Reynish (billreynish) and myself.

Diff Detail

Repository
rB Blender

Event Timeline

Julian Eisel (Severin) edited the summary of this revision. (Show Details)Sun, Dec 30, 6:09 PM
Julian Eisel (Severin) marked 5 inline comments as done.Sun, Dec 30, 6:27 PM
Julian Eisel (Severin) added inline comments.
release/scripts/startup/bl_ui/space_userpref.py
911–912

I could remove the RNA definition of Theme.theme_area (and its DNA pendant) and define the items in Python instead. Or is there any reason to keep it?

950–1015

I'd like to raise special review attention to this code, where I dynamically generate the theme panels/sub-panels. Don't see how this could be done better, but I'm no Python expert at all.

1978–1984

The registering I added here is a bit ugly, though it seems acceptable.

source/blender/blenloader/intern/versioning_280.c
2391

Files saved since this version patch was initially introduced won't have the header use full width. IMHO that's not worth doing extra version patching for.

source/blender/editors/screen/area.c
2345

@Campbell Barton (campbellbarton), this (and other related changes) may make some workarounds for the HUD regions redundant. Worth checking.

Here are some images of the changes in practice.

The Preferences now looks like this:

It uses a narrower window and 2.8-style panels and sub-panels which makes things more logically organized and consistent.

Here are some of the panels opened:

The Preferences use a responsive layout, so that if the window is narrow, the margins disappear:

Another example of responsive layout is in the new way themes are laid out:

Normal:

Wide:

We also added it for studio lights via the flow layout system:

Narrow

Wide:

All these responsive layouts are especially useful if you use Preferences as a normal Editor. Here I replaced the Properties with Preferences:

Here I am editing the theme using the Preferences as an Editor on the side. the items flow so they can be a single narrow column on the side, which is useful for this kind of setup:

Same thing but along the bottom:

Add-ons:

Keymap:

New category added called Input:
This takes the input options from the old Interface category, together with the Input options that used to be next to the Keymap and organizes them together logically.

System>General:
Panels are re-organized here to be much more logical.


All panels open:

System>Files:

Editing:

If technically possible, if there is enough room for the text on the left side of the checkbox, this would be nicer (more consistent):

If technically possible, if there is enough room for the text on the left side of the checkbox, this would be nicer (more consistent):

The text is on the left side of the checkbox.

The layout code used to work like in your screenshot, but it was changed for these reasons:

  • The connection with the 'decorator' (state indicator) was lost
  • We were wasting lots of space to the right of the checkbox while not having enough on the left

We tried several configurations with various benefits and drawbacks:

Looks nice, though I dislike the fact that it's now a two or three-level maze that you have to traverse if you're trying to find something.

The search feature in the Input editor is great, but Preferences really needs a global search like this to help you find that option that you KNOW exists, but just can't find.

If the panels are going to start out collapsed, there really needs to be a visible button or some similar control that will Expand All. Again, sometimes you're searching for something, but often one comes to Preferences just to see what options are available and having to manually enumerate each tab and then manually expand every panel (and then each sub-panel!) seems like unnecessary pain to put the user through.

What if we make whether to "always expand all" itself a preference, defaulting to "always expand" and then once someone learns where things are, they can turn it off and then use panel drill-down to navigate to where they know they want to be?

Well, considering that things are grouped much more logically than before, it will be much less like a maze.

For example, before half of the input preferences were under Interface and the other half was next to the keymap preferences (and would scroll away while editing the keymap!). Text and font settings were scattered in many different places. These are just two out of many examples of poor grouping we had before. The old preferences were scattered in ways that often times made no logical sense.

In the old layout, the different subsections weren't clearly separated, so it was often times not clear if things were placed together because of a logical connection, or simply because there happened to be space in that area. With panels and sub-panels, it is now explicit and consistent.

So, you don't have to open all the panels - just open the one which describes what you are looking for. The categories actually make sense now.

You should be able to much easier find what you are looking for because related preferences are grouped together, and panels and headers have descriptive names.

Think of the example of a cutlery.

The old layout was like this:


Everything was visible but no logical order or good grouping makes it slow and hard to find what you are looking for. The old Preferences used to feel like going down into a cellar or into the attic to find something in a random corner full of cobwebs.

New one is like this:


Yes they are in different sections, but that actually makes it easier to locate.

Still, it would be nice to eventually add search to both the Properties and Preferences to be able to locate any preference or property simply by searching. The new layout makes this a bit easier, because everything is just in a list, so we can much easier filter and display the relevant items when searching.

If technically possible, if there is enough room for the text on the left side of the checkbox, this would be nicer (more consistent):

The text is on the left side of the checkbox.

The layout code used to work like in your screenshot, but it was changed for these reasons:

  • The connection with the 'decorator' (state indicator) was lost
  • We were wasting lots of space to the right of the checkbox while not having enough on the left

    We tried several configurations with various benefits and drawbacks:

Yes, the text on the left looks right. I have not looked at the Blender UI code yet, so I do not know if that's technically possible:
If it was my app ;-) I would do it dynamically - in your picture:

A) If there is enough space for the entire text
D) if not

For example, that screenshot would look like this:

I would do it consistently here as well:

This is a huge improvement.

For the RNA changes, be sure to update addons and other python scripts.

source/blender/makesrna/intern/rna_userdef.c
4016

Do not change the RNA for these undo settings. There are a ton of addons that use them, and we should not break the API much at this point in the release cycle unless there is an important reason.

source/blender/makesrna/intern/rna_userdef.c
4016

Ok, we can easily put the undo RNA back, although then the category will not reflect the one in the UI.

Honestly I don't really know why the Preferences RNA is even categorized by section at all - every time we move something from one category to another, the RNA also has to be updated to match.

But anyway, we can move the undo RNA back for now.

Here I made a patch to change the RNA to put the Undo items back under PreferencesEdit, as requested by @Brecht Van Lommel (brecht).

I also added some slightly nicer grouping in the RNA file, and moved the Weight Paint Range property to the View category to match the UI.

Here's another tiny Prefs patch I thought I could sneak in. It makes it so the custom animation player path only shows when the animation player is set to Custom inside the same panel:

Just makes the relationship between these more clear.

  • Revert changes to RNA path of undo settings
  • If anim player is not custom, gray out path option
Julian Eisel (Severin) marked an inline comment as done.Thu, Jan 3, 11:38 PM

Added a release notes page listing the RNA/Python-API changes of this patch: https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Python_API/Preferences_API

source/blender/makesrna/intern/rna_userdef.c
4406–4407

Don't think "Tabs as Spaces" makes sense in the system section TBH.

@Julian Eisel (Severin): Good point about those three items - although this was the case since 2.5. I fixed it anyway here.

  • Moved use_scripts_auto_execute, use_tabs_as_spaces & author from System to Files.

These three were always in the Files section in the UI, but were wrongly placed in the System RNA.

Patch:

source/blender/makesrna/intern/rna_userdef.c
4406–4407

True, these items I moved here because they were previously under OpenGL, which was plainly wrong. But I agree System isn't the best place either.

Tabs as Spaces and Author should be under Save & Load in RNA, just like in the UI.

This misplacement has been the case since 2.5, but I've got a patch to fix it here.

Pushed a new userpref_redesign branch to the contrib Add-ons repository with needed changes https://git.blender.org/gitweb/gitweb.cgi/blender-addons-contrib.git/shortlog/refs/heads/userpref_redesign.
Other Add-ons don't seem to need updating.

We also need to update the manual-reference updater script in the dev-tools repository. Not sure if I have commit rights for it, I'll poke someone who does if not.

diff --git a/utils_doc/rna_manual_reference_updater.py b/utils_doc/rna_manual_reference_updater.py
index 6758185..4108f2f 100644
--- a/utils_doc/rna_manual_reference_updater.py
+++ b/utils_doc/rna_manual_reference_updater.py
@@ -63,8 +63,8 @@ fw(" This file is auto generated from rna_manual_reference_updater.py\n\n")
 fw("import bpy\n\n")
 fw("url_manual_prefix = \"https://docs.blender.org/manual/en/dev/\"\n\n")
 fw("language = \"\"\n")
-fw("if bpy.context.user_preferences.system.use_international_fonts:\n")
-fw("    language = bpy.context.user_preferences.system.language\n")
+fw("if bpy.context.preferences.view.use_international_fonts:\n")
+fw("    language = bpy.context.preferences.view.language\n")
 fw("    if language == 'DEFAULT':\n")
 fw("        import os\n")
 fw("        language = os.getenv('LANG', '').split('.')[0]\n\n")

Looks good to me now, as far as I'm concerned this ready to commit when you guys are ready.

@Julian Eisel (Severin), the tools repo can be pushed by anyone who can push the blender repo.

This revision is now accepted and ready to land.Fri, Jan 4, 2:52 PM
This revision was automatically updated to reflect the committed changes.

One small issue i noticed with the color picker in this new pref panel layout. When it need to show at the top it sometimes shows when the space isnt high enough. Therefor the top of the picker doesnt show unless we scroll back up a bit.

See below

I think renaming Keymap to Shortcuts would make also more sense. Since you also changing names and making categories and making more sense in general. I believe shortcuts is more explanatory than Keymap, i think 90% would even know what it stands for

@Rombout Versluijs (rombout): The color picker issue is annoying but nothing to do with this change. It has always been like this. In fact it is slightly better now because the Prefs default window size is slightly taller than before.

This is 2.79 - same issue:

This is actually not so easy to solve, because of the way Blender works within an OpenGL context. We can't draw UI elements outside of the windows very easily.

This would be a nice thing to solve, but is not related to Preferences and isn't a new issue.

As for keymap vs shortcuts, the issue is that it's actually not just shortcuts. It's everything. It's how you interact with anything, using your mouse, your keyboard etc.

Yes i see, the function which calculates if it should go above or below seems not to be working properly. Looks like it doesnt add the border height of the window. Or other guess, it looks at a given midline in the window everything above goes above this line and visa versa.

Are the state of the panels and subpanels going to be saved?
It gets cumbersome digging through when starting Blender and opening blend files.

Are the state of the panels and subpanels going to be saved?
It gets cumbersome digging through when starting Blender and opening blend files.

I think in this my mockup will also help because the left panels act like shortcuts. It would be much faster. I dont think the panels open or close can be saved. That normally only happens when you save it as a startup file, so that would be cumbersome to do each time.