Page MenuHome

UI: Vertical Properties Editor Tabs
ClosedPublic

Authored by Julian Eisel (Severin) on Oct 28 2018, 4:31 PM.

Details

Summary

UI: Vertical Properties Editor Tabs

Moves the Properties editor context switching to a vertical tabs region.

Design Task: T54951

The tabs are regular widgets, unlike the 'old' toolshelf tabs. This means they give mouse hover feedback, have tooltips, support the right-click menu, etc. Also, when vertical screen space gets tight, the tabs can be scrolled, they don't shrink like the toolshelf ones.
The tab region is slightly larger than the header. The tabs are scaled up accordingly. This makes them nicely readable.

The header is quite empty now. As shown in T54951, we wanted to have a search button there. This should be added next.

Implementation Notes:

  • Added a new region type, RGN_TYPE_NAVIGATION. Although this could be avoided, I think it might be useful for T54115. Also, this allows theming the background.
  • Having the tabs in a separate region allows scrolling of the tab-bar, unlike the toolshelf tabs.
  • Added a new region flag RGN_FLAG_PREFSIZE_OR_HIDDEN, to ensure the tab region is either hidden or has a fixed size.
  • Added some additional flags to support fine-tuning the layout in panel and layout code.
  • Bumps subversion.
  • Updates the default theme file.
  • There are a few minor TODOs marked in code that I plan to address before committing.

Diff Detail

Repository
rB Blender
Branch
tmp_properties_tabs (branched from blender2.8)
Build Status
Buildable 2317
Build 2317: arc lint + arc unit

Event Timeline

Looks good to me. Nicely done. Obviously the header itself now looks very empty, but the search box will fit nicely there, mirroring the Outliner header.

This looks great. I think we should move the context path into the header, at least until there is a search function.

For the naming "navigation" is a bit confusing because it made me think of the navigation gizmo. Maybe "context bar" is better? I don't have a strong opinion though.

Code generally looks fine.

release/datafiles/userdef/userdef_default_theme.c
212–215

Some changes in this file seem unrelated to the vertical tabs?

Will it be possible to change the position of the tabs, I mean from the left side to the right side of the editor ? So it is easier to just go all the way to the right of the screen instead of aim to the narrow region. It looks really good, can't wait to try this :)

I would treat the header of the Properties Editor window and the space of its bookmarks the same as the space with the Workspaces tabs. An image worth more than a thousand words:

@Brecht Van Lommel (brecht): Good point, the breadcrumbs could go there for now, unless Jacques Lucke is able to port his properties search concept? :)

@Andrzej Ambroz (jendrzych): I feel like putting everything in the header like that is too cramped. There would never be enough space to actually see the breadcrumbs and names. The breadcrumbs you also don’t need to see at all time, so it’s ok if they scroll away.

@William Reynish (billreynish)
My point was to make the header the same colour as tabs background - just like in Worksapces tabs case. Don't mind the Breadcrumbs.

@Andrzej Ambroz (jendrzych): Ah I see. That's just a theme setting, so trivial to change if we chose to do so. It's mostly unrelated to this patch though.

@Lucas Boutrot (thornydre): I don't know if you tested this patch, but that is already possible. The only quirky thing is that the tabs then point the wrong way. Here's a screenshot:

@William Reynish (billreynish) I just tested it, looks really clean, thanks ! Another thing is that it is breaking GridFlow and it stays one column no matter how much you stretch the editor.

  • Fix tabs not aligning correctly when tab-bar is swapped to right
  • Minor Cleanup

This looks great. I think we should move the context path into the header, at least until there is a search function.

Good idea, will do so in a followup commit.

For the naming "navigation" is a bit confusing because it made me think of the navigation gizmo. Maybe "context bar" is better? I don't have a strong opinion though.

"Context" is quite ambiguous too, what about "Navigation-bar"? That doesn't sound too much like a gizmo.

Another thing is that it is breaking GridFlow and it stays one column no matter how much you stretch the editor.

Can not confirm that here. Seems all fine.

release/datafiles/userdef/userdef_default_theme.c
212–215

My plan was to update userdef_defaut_theme.c in a separate commit. Guess that would be fine then.

Can not confirm that here. Seems all fine.

If possible, I would like to be able to choose : the left side or the right side. Just maybe anybody like,if it is located on the right side, but I prefer that it is located on the left.

now emerges space for menus or for search where once were the buttons

Generally LGTM, some minor points.

  • When there isn't enough room this region gets a scrollbar, do we want this? (headers don't do it), think it could be disabled.
  • Ctrl-Wheel could be used to switch tabs (as for toolbar tabs), although not needed for initial patch.
  • Ctrl-Wheel could be used to switch tabs (as for toolbar tabs), although not needed for initial patch.

could such a solution be found also with the pens of the graphic tablets?
for example "ctrl + "pen_click_drag"

slightly off-topic:
the two screenshots in comparison in the main post bring out the specularity of the two light and dark themes.
it is emphasized that the clear theme has some parts inconsistent in the colors the upper left part and the tool icons.
sorry if I write here, but I do not know where to report this so that it is adjusted, maybe someone can report the note in the right place

  • Fix tabs not aligning correctly when tab-bar is swapped to right

Hi. Will we also have the options for top and bottom or it will be just left and right?

If possible, I would like to be able to choose : the left side or the right side. Just maybe anybody like,if it is located on the right side, but I prefer that it is located on the left.

You currently can, but only using the "Flip Region" operator (F5 in the 2.7 keymap). I would prefer to have a right-click menu option for it, just like we have for headers. This can be added once this patch is in though.

  • When there isn't enough room this region gets a scrollbar, do we want this? (headers don't do it), think it could be disabled.

I actually prefer it with scrollbar (although it could be thinner), but this is for others to decide (any opinion @William Reynish (billreynish) & @venomgfx?). This can easily be changed later though.

  • Ctrl-Wheel could be used to switch tabs (as for toolbar tabs), although not needed for initial patch.

Yup, planned this as well. Can easily be added thanks to the separate region.

slightly off-topic:
the two screenshots in comparison in the main post bring out the specularity of the two light and dark themes.
it is emphasized that the clear theme has some parts inconsistent in the colors the upper left part and the tool icons.
sorry if I write here, but I do not know where to report this so that it is adjusted, maybe someone can report the note in the right place

Such feedback is better suited for the devtalk 2.8 UI design thread.

Hi. Will we also have the options for top and bottom or it will be just left and right?

For now it's just left and right. I don't think top/bottom is really needed? We already have the header there.

@Julian Eisel (Severin): This all sounds reasonable to me.

I wouldn't worry about about an option to revert back to horizontal tabs - at some point we have to draw a line with customisability, otherwise everything gets really complicated and difficult to maintain. Well done for supporting the tabs on the right. And yes, a right-click entry for this would make it more discoverable.

As for the scrollbars, either way it's not a big issue as there will almost always be enough space to display the whole column of tabs. But I do tend to agree with @Campbell Barton (campbellbarton) that it's probably nicer to not have them here, and to make Ctrl-wheel flick through the tabs instead - otherwise there are too many levels of scrollbars which is a bit confusing and looks messy,

After testing I think this is OK to commit as far as I'm concerned. We could always add more improvements later, such as the search box and Ctrl-wheel support for switching tabs.

This revision is now accepted and ready to land.Oct 29 2018, 10:28 AM
Julian Eisel (Severin) updated this revision to Diff 12278.EditedOct 29 2018, 11:12 AM
  • Rename "Navigation" to "Navigation Bar"

I won't be around to commit this (and the followups) before later today. Just in case you're wondering.

Hi. Will we also have the options for top and bottom or it will be just left and right?

For now it's just left and right. I don't think top/bottom is really needed? We already have the header there.

Oh, too bad. Some of us still prefer to use horizontal tabs. 🙁

Committed rBab6c7ff2ab1531f. Thanks a bunch for the reviews guys!

This seems to work well in practice, except for the scrollbar. Quite often, it appears and completely blocks the contents like so:

Now that we have Ctrl-wheel for switching, and normal scrolling works for moving up/down, I don't think we need separate scrollbars here at all - I think it would be cleaner and simpler without, and we solve the above issue.

Cheers

Agreed, a scrollbar doesn't belong in this kind of UI element.