Page MenuHome

Vertical Toolbar Tabs
ClosedPublic

Authored by Campbell Barton (campbellbarton) on Dec 4 2013, 8:50 AM.

Details

Summary

This patch adds toolbar tabs as proposed in T37601

Working:

  • panels define own categories, draw as needed.
  • panel pinning
  • uses theme colors
  • uses language translations
  • scales with DPI / retina display / panel zoom.
  • Hide tab-bar when no tabs/panels are visible (or only one tab would be visible).
  • Tabs scale to fit smaller spaces.
  • Right mouse menu on header.

Todo:

  • create useful panel groupings (just in python files)

Areas to check on:

  • tab order? - currently same as panel draw order.
  • method of making space for the tabs could work in view2d code like scrollbars currently do.

Diff Detail

Event Timeline

release/scripts/startup/bl_ui/space_view3d_toolbar.py
73

These are placeholders, adding all the tabs for this is not hard, just takes time (feel free to do if you know python!)

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

I'm not totally happy to have do do this, ideally defining a small margin could be done in a cleaner way. (perhaps follow something similar to what scrollbars do).

source/blender/editors/interface/interface.c
3494

I'd like to remove the need for this, but for now it works OK.

source/blender/makesrna/intern/rna_ui.c
987

this line should be removed.

source/blender/editors/interface/interface_panel.c
1396

var name should be pc_dyn

source/blender/makesdna/DNA_screen_types.h
115

I'll have to comment these better:

  • PanelCategoryDyn / ar->panels_category is a runtime only list of categories collected during draw.
  • PanelCategoryAct / ar->panels_category_active is basically a list of strings (category id's).

Clicking on a tab moves it to the front of ar->panels_category_active, If the context changes so this tab is no longer displayed, then the first-most tab in ar->panels_category_active is used.

This way you can change modes and always have the tab you last clicked on.

You can update the diff by creating a new diff, in the second step it can be attached to this revision then.

The main thing I'm wondering about this is if we shouldn't be making categories some you register explicitly instead of being created by panels implicitly. Main reasons to have it explicit would be that you can more easily add icons, change the label text without breaking scripts, and give them a poll function. The disadvantage I think is that it's more tricky for addons, with just a name two addons can 'register' the same category as another addon quite easily. Perhaps it would still be possible to make kind of merging would automatically even if you have a PanelCategory that you have to register.

I'm not sure what your opinion on this is, just would like to avoid doing it in a way that turns out is not flexible enough, and then we would have to break scripts to fix it.

On the visuals (viewing this on retina):

  • Overall it looks a bit bare and flat compared to the rest of the UI, maybe some UI designer can propose tweaks to make it fit better
  • The tabs should have less roundness I think
  • The sides of the text needs a bit more spacing, feels cramped now
  • The text doesn't seem to be centered correct vertically (actually horizontally because it's rotated)
  • If there are tabs the region should be wider by default

@Brecht Van Lommel (brecht),

So AFAICS main issue is how we define categories, TBH Im not that big a fan of icons on tabs in this context.
Also checking similar uses for tabs in other 3d applications icons are not used. also used to be a lightwave user and found their tabs easy to follow without icons, since there are normally <6, you tend to know which one to use by their size, location and a glance at the word.

But the point that we can't easily reference a category remains...

If we change our mind we could have it set via the api brainstorming...

bpy.types.SpaceView3D.panel_category_icon("Animation", icon='ANIMATION', regiontype='TOOLBAR')

... a bit clumsy but workable too. could be made less verbose to access.

Visual stuff can change (Im not so fussed - and agree some mockup would be nice), latest patch looks like this:

Tabs on (fake) retina display.
http://www.graphicall.org/ftp/ideasman42/tabs_big.png

UI Design
@Paweł Łyczkowski (plyczkowski) has done a full mockup of @brechts top bar reshuffle, which includes tabs. I suggest we use that (excluding colors of course) for the tab design. He's doing a great job of keeping the style consistent and is well polished. He's also already doing a bunch of icon work so I think it'd be good to use his work as a base:
https://dl.dropboxusercontent.com/u/6959287/Art/Blender%20UI%20Mockups/mockup02_06_nodesc.png

He also did a quick pass on the toolbar tabs: https://dl.dropboxusercontent.com/u/6959287/Art/Blender%20UI%20Mockups/34567.png (ignore the bottom highlights and the weird spacing, though)

The current angular look of the tabs doesn't feel consistent with the rest of Blender. Going on @Paweł Łyczkowski (plyczkowski)'s mockup, the tabs need:

  • horizontal edges on top and bottom
  • rounded corners, same as buttons
  • flat/shaded should probably be defined by the theme, just like regular buttons, value fields, etc
Campbell Barton (campbellbarton) updated this revision to Unknown Object (????).Dec 5 2013, 5:36 AM

minor updates to correct panel offset

I like @Paweł Łyczkowski (plyczkowski) design, looks modern and understandable.

The code version from Campbell is visually fine, I'd prefer a small spacing between the tab though (see https://dl.dropboxusercontent.com/u/6959287/Art/Blender%20UI%20Mockups/34567.png) Opinions?

I think the small spaces give it too much depth, they distract me, my eyes are drawn towards them.
They do look cool, like piano keys, but i dont want to be distracted by them.

Here it is more polished with a closeup - notice the gradient (I don't know if that's possible to add), and the lightly paler than usual embossing (visual contrast on the edge on the screen, and the one that goes vertically, and especially diagonally, is visually intense and distracting).

And the full version. The small gaps between tabs decrease clutter and increase readability.

I also think if they were wider horizontally, that would be better - also reduces clutter, makes it easier to click on them - I suppose they will be clicked fairly often.

That last version looks good to me @Paweł Łyczkowski (plyczkowski). The slightly wider tab makes it feel more comfortable, less cramped, and easier to click like you said.

Yes, latest version is great. :)

@Campbell Barton (campbellbarton) I'm unable to apply the latest patch. I get this:

Created and checked out branch arcpatch-D75.
Checking patch release/scripts/startup/bl_ui/space_view3d_toolbar.py...
Checking patch source/blender/blenkernel/BKE_screen.h...
Checking patch source/blender/blenkernel/intern/screen.c...
Checking patch source/blender/blenloader/intern/readfile.c...
Checking patch source/blender/blenloader/intern/writefile.c...
Checking patch source/blender/editors/include/UI_interface.h...
Checking patch source/blender/editors/interface/interface.c...
Checking patch source/blender/editors/interface/interface_panel.c...
error: while searching for:
	uiBlock *block;
	Panel *pa;
	int retval, mx, my;

	retval = WM_UI_HANDLER_CONTINUE;
	for (block = ar->uiblocks.last; block; block = block->prev) {
		int inside = 0, inside_header = 0, inside_scale = 0;
		

error: patch failed: source/blender/editors/interface/interface_panel.c:1125
Checking patch source/blender/editors/screen/area.c...
Checking patch source/blender/makesdna/DNA_screen_types.h...
Checking patch source/blender/makesrna/intern/rna_ui.c...
Applied patch release/scripts/startup/bl_ui/space_view3d_toolbar.py cleanly.
Applied patch source/blender/blenkernel/BKE_screen.h cleanly.
Applied patch source/blender/blenkernel/intern/screen.c cleanly.
Applied patch source/blender/blenloader/intern/readfile.c cleanly.
Applied patch source/blender/blenloader/intern/writefile.c cleanly.
Applied patch source/blender/editors/include/UI_interface.h cleanly.
Applied patch source/blender/editors/interface/interface.c cleanly.
Applying patch source/blender/editors/interface/interface_panel.c with 1 reject...
Hunk #1 applied cleanly.
Hunk #2 applied cleanly.
Hunk #3 applied cleanly.
Rejected hunk #4.
Applied patch source/blender/editors/screen/area.c cleanly.
Applied patch source/blender/makesdna/DNA_screen_types.h cleanly.
Applied patch source/blender/makesrna/intern/rna_ui.c cleanly.

 Patch Failed! 
Usage Exception: Unable to apply patch!
Campbell Barton (campbellbarton) updated this revision to Unknown Object (????).Dec 6 2013, 5:23 AM

Updated patch, mainly for looks/theming.
http://www.graphicall.org/ftp/ideasman42/tabs_big2.png

Campbell Barton (campbellbarton) updated this revision to Unknown Object (????).Dec 6 2013, 8:59 AM

Add panel pinning so a panel can optionally show no matter what tab is selected.

Just one word, great! :)

looking really great, really like pinning option. Just a thought..could it be possible to change the vertical text with icon?

Brecht Van Lommel (brecht) requested changes to this revision.Dec 9 2013, 8:57 AM

I can't find much to comment on in the code, looks pretty good.

The white pin icons in every panel though, that's a bit too much I think. I'd put that functionality in a (right click?) menu and if it needs to be fast perhaps a shortcut key that you can press over the panel (header). Maybe I'm underestimating how often you would use this. If it needs to show always I'd at least want a more muted dark pin icon, but I'd rather not have it visible always.

An option would be to turn that right top corner of the panel into a button that opens a menu to move the panel, pin it, collapse other panels, etc. I'm not sure if people would be happy to have moving panels one click further away, but personally I almost never reorder panels.

source/blender/editors/include/UI_interface.h
678–683

I'm not sure why these are exposed in the API, seems they are not needed here.

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

Is there any reason to restrict this to the tools region instead of setting this to true and detecting if there are any panels that have categories?

I guess it could get out of hand with addons adding categories everywhere.

source/blender/makesdna/DNA_screen_types.h
139

I'd call this PanelCategoryStack but it's a matter of preference.

Regarding pinning,

This is one thing I wasnt so sure of where best to add it. But I think the functionality is important.

  • Being able to quickly pin-and-switch tabs is nice, If this feels like a hassle to do, I think users will just put-up with switching between tabs. Putting it behind a menu can work but Im not keen on doing this especially if you need to open a menu to un-pin, which also makes it hard to know whats pinned at a glance.
  • If pin in somehow hidden behind a menu then as long as the key shortcut to toggle pinning is also shown, maybe this can work OK, (not convinced but at least its not a hassle to access).
  • When using this feature, I had the desire that pinned panels headers could draw slightly different (stand out more somehow). So perhaps that could replace a pinned icon?.
  • Pinning icon is too contrasting and bright - this comment was made by users too, and I agree with this.

Agree that users wont like a submenu to move panels...

There is one other issue to resolve - how to scale down tabs when they dont fit.

source/blender/editors/include/UI_interface.h
678–683

Some of them are needed, UI_panel_category_active_get, UI_panel_category_add, UI_panel_category_clear_all, UI_panel_category_draw_all -- since they make up a small API, I didn't see the need to split into some public, some private.

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

There isn't any important reason, since tabs wont display if none are define, we could remove this var, however it might get annoying if a single addon defines a category in an area where none of the others do (like properties), so I was thinking to make a conscious decision to only enable this for some kinds of regions. Later on we could enable more.

source/blender/makesdna/DNA_screen_types.h
139

The name is nicer, but imho its not any more correct or descriptive, in fact the way this works is a little confusing and doesnt fit well into some name - since its a list of panels you last clicked on.

Am fine with calling it this too though, just saying I dont think its any more correct.

how to scale down tabs when they dont fit

How about making the tab area a scrollable area, independent of the panel area? The scrolling would be with Mouse Wheel and the MMB - we already have MMB scrolling in other parts of the UI - the problem with this is that it is pretty non standard, and thus have low discoverability. Mouse Wheel is already used for tabs in Firefox (not sure about other browsers), and MMB I would add for consistency.

An alternative is to squash tabs when they don't fit, at the expense of the names becoming unreadable.

I agree on all of the above points about the icon and such. Here's a quick mockup for a proposal that I think would work quite well.

Panel Menu

  • Adds a small + icon to the panel (which is much less visually noisy than the pin icon)
  • Plus icon presents menu for the panel with all available options (pin, unpin)

This way we don't change the panel movement method, and we also build it out to allow for future feature additions for more customizable panels.

An alternative to the icon is to simply make the menu a RMB context menu, but this is not very discoverable.

We could instead have a "..." tab that you can click and that will show a menu of the tabs that don't fit. I think such a menu is better than having a small scrollable area, that might be confusing to manage and somewhat strange when the active tab scrolls out of view.

Hi. I tried to apply this patch to my local branch, but whatever i try, it fails.
In order to get my git repository clean i did this:

$git checkout master
$git reset --hard HEAD
$git clean -f
$git pull --rebase
$git status
# On branch master
nothing to commit, working directory clean

From here i tried 2 ways:

Using arc:

arc patch D75

That ends up with errors: http://www.pasteall.org/47917

Apply the RAW diff:

So next i went back to this page, right clicked on the "Download RAW Diff" link at the top of this page and stored the result in a file: ...projects/D75.diff Then after cleaning up git (as indicated above) i did:

git branch D75
git checkout D75
git apply ../projects/D75.diff

That ends up with other errors: http://www.pasteall.org/47913

Is there any other way i can try ?

I am working on windows 7,
I have installed msysgit.github
I use the git bash command window

The patch doesn't apply cleanly anymore because of a change made in rB1ed822202f5b8c52cc4e7d25abed02342a880cfe. The workaround is to use:

git checkout 1ed822202f5b8c52cc4e7d25abed02342a880cfe~1
arc patch D75

If the code review is create with arc it will actually remember the commit the patch was based on, and it should automatically check out that one before applying, but in this case a diff was uploaded manually so that information is missing.

If you manually apply the diff download from here, you need to use the "-p0" flag because git assumes "-p1".

Campbell Barton (campbellbarton) updated this revision to Unknown Object (????).Dec 11 2013, 9:09 AM

Updated patch against latest master.

From discussion with Jonathan Williamson.

  • swap location of pin and grab button
  • make pin icon more subtle

Also as Brecht suggests, rename PanelCategoryAct to PanelCategoryStack

This is how the new pin icons looks:
http://www.graphicall.org/ftp/ideasman42/pin.png

If others are not happy with it can someone design a different one?

Also we should choose weather to use an outline or not, I was thinking to make this look similar to the drag button when in unpinned state.

The icon looks fine in general, but a bit pixelated on a Retina screen: http://www.pasteall.org/pic/show.php?id=63830

I would like to chose color for pin/unpin. Is it going to be themable?

For the pin icon, I was expecting something a bit smaller, maybe just the existing pinned/unpinned icons scaled down and in half transparent dark grey? It looks a bit strange like this to me because the pinned/unpinned state doesn't show it actually getting pinned.

Further, perhaps we should only show it when the mouse is over the panel header, the same could be done for the grip widget.

@Brecht Van Lommel (brecht), the reason I didn't want to use a grayed out icon is it would look like its disabled, especially when the properties space uses same pin icon which isnt grayed out.

it could be good to get a mockup we can agree on so I can finish off the patch (AFAICS this is the main blocker at the moment).

Excluding the icon, I think it looks good functionality wise. If the code side is good then I suggest we go ahead and commit. Then update the icon once someone is able to design a more optimal one. It's relatively simple and I can even do it if needed.

Pin icon mock-up. The icon is smaller (90%) and the color is a little bit grayer. It has a similar effect as taking back the opacity. The outline should remain black.

I would make the option to pin in the RMB menu, when clicked on panel. Then the pin icon would appear.

I would make the option to pin in the RMB menu, when clicked on panel. Then the pin icon would appear.

Forgot the reasoning. The reasoning is - a repeating icon in the GUI looks awful, only really subtle GUI elements can withstand repeating (little plus signs, triangles, drag areas). And it is advanced functionality, so no need to put it on the first GUI level, can be hidden behind a RMB menu.

HI, I try doing mockup for this, check it out ! The idea is to put it beside triangle icon and to group icon together, so it'll more cluttered IMO. The pin button taken from node editor.

Cheers

I posted this earlier on IRC already: https://dl.dropboxusercontent.com/u/675429/sidebar_mockup.jpg

This would improve the current concept in two ways:

  1. You have indicators what functionality is available if the tool shelf is closed.
  2. You can directly access the parts of the tool shelf you are looking for.

Campbell mentioned that this would collide with the non-blocking UI-paradigm of Blender. To me it seems that one might argue that the entire toolshelf is not conform with the non-blocking paradigm.
Also: My proposal basically just means, that one would replace the already existing "+" indicating the tool shelf in the 3D-view by direct "links" to the different panels. It just cuts out the unneeded step of having to click "+" to get to your desired destination only afterwards.

What i like most in Okapi's suggestion is that the vertical tabs are placed on the other side of the sidebar. In my opinion this looks much nicer and the tabs are much easier to read when they are standing out in the view as demoed in the image.

And in addition only the tabs take some extra space away from the View while the original design does shift the entire sidebar inwards to add the needed space for the tabs.

Regarding the visibility of the tabs when the sidebar is closed: i like that as well. This clearly tells me "There is more here". However i also find the "+" icon convenient, so maybe this could be controlled via user preferences...

The inactive tabs are way too noisy in my opinion. As long as there's enough spacing between the tab labels, why not use the label only? Or just a thin line to separate inactive tabs:

On hover, it could still draw the tab border. See Mozilla Thunderbird tabs for instance!

@codemanx, I quite like the tabs you propose, prefer having some divider. (the one on the RHS)

Yes, use the one on the right , with a subtle divider. :)

Agree with Dingto, use the right one

@codemanx: LEFT one :)

Since the space here works as separator I prefer the left one that makes the best job.
The right one even with small divider fills this space and destroys all the beauty of visually clean UI.

Thank you for your mockup.
It would be a great If whole UI of blender will use spacing as separator instead of framing :)

If the separator colors would be individual theming colors*, they could be set to the panel background color (or if they were RGBA, set to fully transparent) = no separator!

* distinct separator color, but maybe used for all sorts of dividers? Otherwise separate color only for the tabs.

Everyone would be happy :)

Campbell Barton (campbellbarton) updated this revision to Unknown Object (????).Dec 16 2013, 3:26 PM

Updates:

This should contain all updates agreed on in recent discussion.

  • icon hidden when panel unpinned.
  • rmb menu for panel header which can toggle pinning.

Also...

  • tabs now scale with panels.
  • change inactive tab drawing (as suggested by codemax)
  • added alt+LMB toggles pin.

Hey @Campbell Barton (campbellbarton), good work! So far everything seems very good and works as expected. Just one small fix needed that I can see. When using Region Overlap for transparent toolbars the tabs do not take the transparency into account.

Screenshot: https://www.dropbox.com/s/yefczxg01t06fhm/Screenshot%202013-12-16%2009.21.08.png

The tab should match the transparency of the panel.

Looks good to me!

source/blender/makesrna/intern/rna_ui.c
1013–1020

Did you intend to fix these XXX's still?

source/blender/makesrna/intern/rna_ui.c
1013–1020

This one is harmless but overkill, I dont see a simple way to fix as long as RNA is used, I guess we could search for this panel in all the screens areas, but its overkill.

I moved PNL_PIN to DNA so the flag didnt need to be redefined.

Hi folks
I don't wanna be a complainer, but i almost dislike the tab implementation.

  • vertically thus textorientation makes it almost a bad user experience
  • fontsize and colouring is plain bad contrast as is
  • the resulting dark bg for tabs feels like a style break when peeking on the gui

I would suggest to think about alternative solutions:

One example could be a more modern way take from websites:

http://www.jensverwiebe.de/Other/tabs_alternative.jpg

Take into account not everybody has eagle-eyes, but in the mains i think the introduction
of tabs as an additional styleelement is just disturbing as is. ( perhaps horizontally is much better as in
Andrew Price's video, these where much more graceful and fresh )

Jens

If you want to get involved in the UI design process you just need to do it earlier, at this point the design is not going to be changed to something entirely different. The styling of the tabs could be tweaked still but otherwise it's not really fair to the developers of these features to expect them to redo their work when there was a long time to give feedback.

I said from the beginning on in IRC discussions, that vertical tabs is suboptimal.
I told ppl that i experimented a lot ( using Qt designer for example ) with tab-orientation
and got no good perceptive results.

Imho it's never too late to redesign things, that don't work good.

But in the end let decide userbase then.

I give up here. I cannot read these tabs and have no benefit from it. Period.

Jens

@jens verwiebe (jensverwiebe) there's adjustments still being made still to ensure tabs are readabl, such as: rBcde3ff75d9771e526f1e927dc58c7f314c3bfdcb

@Jonathan Williamson (carter2422)

.. i know there are still especially color/contrast adjustments to be made.

But now seeing this in the wild, i even more doubt vertical tabs where a good choice.

I'am not talking about the grouping, thats perfect, just the visual approach is not.

In between even more ppl told me "uhhm ... what is written in the tab labels ? ... cannot identify .. "

I really recommend to think this over, gui change is not a biggie, grouping of the properties can be left untouched.

Jens

@jens verwiebe (jensverwiebe) I do experience the samilar pain as yours. As English is not my home language (and even if it is), I have to wry my neck every time to make sure I can switch to the target tab. so I think it brings more pains for the neck rather than eyes :P. So I agree with you on this point.

However, Brecht and carter2422 are also right. The current solution can be reasonably adjusted, I suppose. IMHO, since the number of categories is very countable, I think a few icons could be fairly acceptable.

My humble idea:

And hope it won't change the current code too much.

Updated with the plain color version, which looks hopefully clean a bit.

To be honest, I do love the current vertical tab idea, it is definitely the smartest one. but just... I really wish to see any possible improvement on the readability for the tabs. :)

Have you tested if moving the tabs "inwards" (on the right side for the tool shelf, on the left side for properties panel) makes them better readable ? This was another user's (okapi) proposal actually and i liked that idea because i personally found it easier to read the tabs that way:

https://dl.dropboxusercontent.com/u/675429/sidebar_mockup.jpg

This even saves some place. And using icons and tooltips together with okapi's idea would be even more awesome (i imagine).

I asked for that already a month ago, see #comment-46, but i suspect this has been overlooked by then ? Or maybe i missed the reasoning why that idea was bad. However maybe take another look on this as it might be of help ?

To be honest, In my own opinion, I can see some good point there. But still, vertically written texts are relatively hard to read for normal people. I believe this is true, no matter what language it is (and I've already tried mine with the i18n setting). In other words, I think it would be much less identifiable than, say, a single icon. But that's just my personal opinion. Again, I'm from a non-English spoken country, although I touch English everyday. :)

@Gaia Clary (gaiaclary) That's really clever imho! It makes the tabs clearly readable and stand out

And what's even more important: It makes you access your tabs quicker when they are also shown when the panel is collapsed! That is a big leap forward to a faster workflow.
So really a big "yes" from my side!

@Campbell Barton (campbellbarton) what do you think? Is this a lot of additional work? In fact only big parts of the panel would be hidden by hitting (T) (so it would be always visible partly)

@Leon Cheung (leon_cheung) icons were discussed and rejected (see my reply to andrewprice) T37601

Having tabs outside the region is tricky... not sure it can be made to work without a lot of hacks. Im not sure its worth doing.

I've tested the tabs now and I'm not convinced that they are better for workflow and don't fit into the great Blender UI. This is my current opinion and other users may disagree.

  1. Is it possible to make them optional in the preferences menu? My workaround now would be to pin all panels down so I can see them all.
  2. When I click and drag a panel, I can change the order of them. Can this be done for the tabs? The reason for this request is a better workflow.

I noticed that the Rigid Body Tools panel in Physics vertical tab always collapses by default, which is unlike other tool panels. Maybe it can be improved some?

There's no bl_options = {'DEFAULT_CLOSED'} for the ridgid body panel, it must be stored as state in startup.blend...

re: rigid-body panel, We can version patch this in the code, or (cheap trick), change the panels identifier so its re-initialized.