Page MenuHome

Reorganize 3D View Toolbar
Closed, ArchivedPublic


The current 3D View Toolbar is very messy, in both Object Mode and Edit Mode. It's also become overly long, tool selection is spotty - some tools are there that probably shouldn't, and others that are there probably should not be - and it's inefficient to use.

The 3D View Toolbar can be greatly improved by simply reorganizing it and reviewing all items that are in it, adding and removing items as needed. This organization should be based on the new vertical toolbar tabs.


  • Implementing vertical tabs to improve organization of toolbars is now in master and ready for organization T37601



Event Timeline


@Jonathan Williamson (carter2422): that's ok with me, whatever more organized ordering can probably be transferred to various UI design for a toolbar.

I have some concerns about making the toolbar wider or narrower as in the mockups. Currently there are a bunch of panels in this region here besides the toolbar that have been designed to work with a particular width in mind. I don't mind if you make the python toolbar code smart enough to adapt as the user changes the width of the region, so it works with only icons, single column text and two column text. But I'm not a fan of making the two column layout the default, it just takes up too much space in my opinion.

Starting work on icons for all tools would be great! Just make sure to do them in SVG format so we can rescale them (for retina or possible toolbar with larger icons). And follow the color palette and designs of the existing icons, although you may need to define some additional color conventions to indicate things like adding or removing.

@Brecht Van Lommel (brecht), okay great. I will add subtasks for each mode and region as needed. Not all areas need reorganization, but some definitely do. I'll use @Paweł Łyczkowski (plyczkowski)'s as a starting point but see how it can be adapted for single column and such.

I'll also add tasks for the icons.

Is there a need for text in the toolbar at all?

I can understand the benefits of it for the initial learning period, but once we've learned them and are working autonomously we work via recognition. And if we forget: tooltips are a backup, like everywhere else.

Having it change from text to icons seems like an unnecessary and possibly annoying feature (depending on how it's implemented).

I think text-free toolshelves are a hurdle at first, but if the icons are designed well enough they shouldn't be a problem in the future. And in return the user get's a lot more workspace.

@Andrew Price (andrewprice), a icon-only toolbar is not a bad thing in my view, but that poses some serious problems for addons. We can't force all addons to only use icons. Switching to icon only would break basically 99% of addons that currently use the toolbar. To do this we'd need to restrict addons from using the toolbar.

@Andrew Price (andrewprice)

My previous reasoning was:

"That is ok for a 2D app, but in 3D there just too much obscure and complicated operations for this to work. Examples: create a distinguishable icon set for Mark Seam/Clear Seam operations, and another one for Mark Sharp/Clear Sharp. Create icons for Relax, Scale Along Normals, Merge, Merge Doubles, Unify Normals.

Icon + Text combines the strenghts of both. It gives you a visual description and a textual description. Combining both informations, you deduce what the tool does."

But after looking at the icon-only toolshelf- it actually feels quite good. Even though some icons are non-descriptive (ex. Mark Sharp), the section icons provide context for them, so they are possible to read. Possibility to switch between icon-only and icon+description would probably be best.

@Lee Carter (Carter) 2422

We could make the toolshelf icon-only without making the toolbar thinner - just put more in a row.

@Paweł Łyczkowski (plyczkowski) @Andrew Price (andrewprice), so long as the width stays relatively the same then going icon-only for all (or at least most) the default tools is fine by me. Where the problem arises is if we try and do a thin toolbar like you see in Photoshop or here:

I would be great idea to add in python the option to define custom icons. The default icon list sometimes is not enought, so you must use the default icon or add something that fit, but this is not the best way and creates inconsistences. or example, in my addon Archimesh, I would like to add a room icon, column, door, etc.

But the custom icon has some issues, for example, how maintain a "look and feel"...maybe, create a guidelines as the existing in Android or Iphone would be great.

If we don't add guidelines, we will get a Blender "hippie". I have developed applications for years, and one of the thing that makes an application looks "amateur" is to have diiferent "look and feel", so the icon subject must be decided very carefully.

If someone is interested in Android icon guidelines, this is an example:

This is what I refer with a design guidelines for custom blender icons for Addons.

Some customizable toolbars (like Firefox) have the option to have icons or text+icons. It could be added as an right-click menu option.

@Brecht Van Lommel (brecht)

follow the color palette and designs of the existing icons

I fear that they are too colorful to be bunched like that. A splash of color here and there is great for navigation, but 20 colorful icons is too much. That's why GUI designers usually heavily restrict the color palette for tool icons:

  • Photoshop - all grey
  • 3ds max - all grey
  • Maya - restricted color palette (blue and red)
  • Modo - restricted color palette (blue green and violet)
  • Cinema 4d - restricted color palette (grey orange)

Blender icons tend to go into grey blue orange area. I think I would go in the direction of doing the base of the tool icons in gray (like the concepts), and indicate the action on the icon in blue or orange. I will prepare mockup icon sets to check how that looks.

@Jonathan Williamson (carter2422),
on that picture you've shown that having a lot lot of icons is a holy mess (I guess you've meant that!). I agree here almost on 100%.
Actually.. personally I need only 2-3 clickable commands presently: set smooth, set flat and some others. This leads me to the idea that the layout must be highly configurable. This feature set usability was proven in Acad and Rhino (at least).
If a user doesn't need these "extrude", "move", "rip" and etc. to be presented visually then it can be removed. We have shortcuts :)

@Antonio Vazquez (antoniov),
it's a good point that any addon creator could design own icons leaded by recommendations written in Blender docs. And many addons NEEDS custom icons because a lot of them consists of "creepy words" (long and not happy describing) that takes additional space also.

@prout reprout (all)
about anxieties (yes, it's real IMHO) that still the addons will take width even if the standard Blender's tool set will be "iconified".
Well.. Is it possible to make the standard section "fixed" and all additional stuff will be presented in another section? This can be designed that addons' section will be "minimizable". If you're not using addons at a moment - just click and it's not taking a space there. A good decision (IMHO) can be borrowed from Photoshop: addons can be presented in floated windows or additional panels (currently it's named "editor type"). You click on an icon and a little narrow section transforms in a whole menu with all UI that was written by addons' authors.
I think that this "separated" design will allow main Devs keep Blender's UI light and clear without hard restrictions for addons' authors.

P.S. The most irritating problem now is the "hollow list" "bug". When you have a lot of expanded command lists (usually because of addons) in one editor (lets say "Mesh") try to scroll to the end and then enter in another editor (in my example it's "Object") - you see the empty field. And what you need... scroll up! Why is it not scrolling up to last commands (I assume it can be calculated relatively to a last position in 1st editor) automatically? I guess it's in ToDo already but I point to this because it's worse (at least for me) presently.

@Moolah Nasreddin (moolah): it's really bad indeed that panel may look empty until you realize it's scrolled past the end. Would be better if the scrolling position was remembered individually. Since it's not, blender doesn't scroll up, so that you can switch back to the former tab and retain the scrolling of those panels.

yes, "individually" can be the best solution here. I've realized. I guess that something (pardon my code terms illiteracy) isn't well prepared for this yet or it could be already fixed a year ago... not sure though...

@Jonathan Williamson (carter2422) On the topic of addons, I actually don't think they should be anywhere near the toolbar at all. I honestly think it's one of those things that we've gotten used to over the years, but if you really think about it, it doesn't make a whole lot of sense that they're lumped together.

An addon typically has a bunch of sliders and configurable options, whereas the toolbar has one-click tools. They don't have a lot in common. They are much more similar to the properties panel.

So I think an idea could be to make them appear in the properties panel in their own separate panel (that appears only when an addon is used).

Here's a quick mockup:

The benefit is that it's easily found (no scrolling or bringing up the toolbar) and the developer has a much space as they like to flesh out their controls.


@Andrew Price (andrewprice): I agree, addons do not really belong in the toolbar. A toolbar contains tools (operators), but shouldn't contain the settings, sliders, input fields, etc. for these tools. (ie. the way most addons work, adding their settings into the toolbar) They belong either in a separate panel, a popup, or somewhere else. For tools with settings that cannot be changed afterwards (eg. rings of a UV sphere), a popup might be the better solution.

As for the large number of operators of a 3D program vs. number of icons: other very complex 3D programs also have icons for many many tools. Looking at the CAD program I use at work, there are maybe about 20 general toolbars and around 100 toolbars in all that are mode-specific (shape design mode, mockup mode, digital prototyping mode, sheet metal mode, etc.). Each toolbar contains around 5-10 tools, and many of them have a small popup for 3-10 sub-tools, all icons. Learning them requires hovering for a popup with their names, but once learnt, it is fast to use and takes up minimal screen space.

@Zsolt Stefan (zsoltst) The problem with popups is that one the mouse moves away, the popup disappears. Blender 2.49 functioned this way, and it was changed because it was unfriendly. Also, many addons have lots of settings, so a popup would block your scene. Plus, it prevents you from being able to move around your model as you change the settings.

So for these reasons I don't think a popup is a viable solution.

As for Add-ons, it depends on the Add-on. If it's a tool, it should be in the toolbar. If it's an object type, it should go into the Add Object menu, if it's new I/O capabilities it should go into the Import/Export menu, etc.

@Andrew Price (andrewprice)


Could you give an example of such a popup in 2.49? I just tried to find one and failed.

If addons will be as popups - this can block a scene (usually not a whole space and actually with semi-transparent panels now it's not that bad)
if addons will take space in properties - it will be a constant jumping from tools to addons. Although many addons acts in Object and Edit modes.

+1 for last @William Reynish (billrey) had said:
The UI must be logically proven. So Addons which belongs to Edit mode must be NEAR buttons for this mode. The addons for Object mode must be near Object mode buttons.
This is logically relative to contexts.

My POV: I still think about an additional choice in "editors" section (where you choose 3dView, Properties, Outliner and etc.). It will not be a big change (I guess) for Blender's inner design and any user will be free to place it anywhere, scale it and etc.
Any thoughts?

At least Addons (if not the previous variant) must be presented near Tools. Ideally it should be moveable. A kind of a docking panel. So if somebody wants to place it near Properties - why not? If it's not hard to implement.
+ one more thing: what to do with Addons like "Cursor memory"? (sorry I don't remember the right name) Currently these are in "N"-section. Logically it must be there. But in the current UI it creates a mess.

@Paweł Łyczkowski (plyczkowski),
Sorry, I've didn't noticed your 1st message! How could I? :)) Sometimes my head jokes with me )
I've looked at the 1st mockup - I think it can be good if sections will be expandable.
For example: my interests in this panel belongs only to Shade and UV parts. I don't use other icons because I remember the most
of shortcuts for them or create my own (for Bridge and Bevel and some others). But sometimes I could use these icons so an expandable version could be the best option.
I'll pass the 2nd mockup.
Icon only toolshelf is great when you've placed all icons manually, by yourself. So only if it's configurable. It's working perfect in AutoCad. Users delete unnecessary icons and left only those they want to use often. Panels are floating and you can dock it anywhere - vertically or horizontally (it will be super-perfect for Blender but I guess it's hard to embed in the current UI).
Everything other is accessible through menus or via shortcuts.

@Andrew Price (andrewprice), like @William Reynish (billrey) mentioned the location of an addon depends entirely on the type of addon. There are lots of misplaced addons, but that's the developers problem more than a Blender problem. For example, my Contours addon is explicitly a mesh tool that is only used in the 3D View, thus it should be in the toolbar. But something like a Materials Editor should definitely not be in the toolbar.

I do think there's an abuse of the toolbar by many addons, but that's a different story.

Since it's quite apparent that addons and general organization are large contributing factors to the toolbar problems, I think it may be appropriate and necessary to extend our current toolbar functionality a bit. I think the best way to do this is through tabs.

Proposal for Tabbed Toolbars
Here is a proposal, and rough implementation by @Campbell Barton (campbellbarton), for Toolbar tabs (and layout tabs, but these can be ignored for now):

If the above proposal looks good as a starting point then I will add a Design Task and begin working with Campbell on the development. He has already agreed to develop it.

@Jonathan Williamson (carter2422) Nice! Although I am against vertical text in design, I am afraid that it's the best solution. There is not enough space for horizontal tabs with text, and icons are much less informative.

@Jonathan Williamson (carter2422) Looks great! Curious though if changing the tabs could change the objects state?
For example, hitting the Sculpting tab could automatically take you into Sculpt mode?

@Paweł Łyczkowski (plyczkowski)
The 2.49 reference was about the popups for things like adding a sphere. Where the popup would appear to ask about rings, radius etc. But it was moved to the toolbar to be less disruptive and more in line with the users workflow.

@Paweł Łyczkowski (plyczkowski), agree - am not a fan of vertical text, but also dont see much better alternatives (a vertical stack of toggles could work but seems clunky too).

@Andrew Price (andrewprice), Tabs could change mode but think it would be better not to, only be a view on the toolbar.

  • If we do want to make tabs control modes - it can be done but is a bigger topic and raises questions, for eg, you would want maybe 3-5 tabs for editmode [Add, Modify, Clean, Reduce, UV] alone, but not show them in object mode. (basically the tabs may only make sense based on the current mode - some tabs switching modes, some not - IMHO confuses things).

So I'd propose first make this simply a way to arrange tools more logically.

Note: One thing thats nice about text categories (tabs) in general, is this is quite simple to extend with addons, Every panel just defines a category label, then gets added to this tab, to define a new tab would just be to make a label unique to this addon. (this is how the addons user preferences categories already works).

@Jonathan Williamson (carter2422): Interesting idea regarding tabs. But it's not really clear how this will help.

For example:

  1. In The proposal it says that tabs will let the toolbar be smaller. How? Surely it only gets larger to have extra space for tabs?
  2. If the toolbar is split into tabs, the user will have to constantly change tabs to find the tool he/she wants, adding extra steps.
  3. How would this fit with the idea of having tabs in the main header of Blender as @Andrew Price (andrewprice) and @Brecht Van Lommel (brecht) have both suggested?

@William Reynish (billrey). re: Point 2, I used a 3d application that did this (are we allowed to reference other apps?), and it wasn't really annoying to switch between tabs. The categories are based on workflow so you dont end up switching all that much, and for tools you really use all the time you probably learn the key shortcut, (eg, you wouldn't switch to 'Animation' tab all the time to insert a keyframe, you figure out that its 'i'key).

Of course its a tradeoff though, at the moment we dont add items to the toolbar that could be good to have because it introduces too much scrolling, so they're in menus instead- or we do add them ... and accept scrolling.

We could allow shift-clicking on tabs (which breaks tab analogy a bit), so panels from multiple tabs can draw at once if you run into a situation where switching happens to be annoying. Disregard this, pinning is much better idea - suggested below

@William Reynish (billrey),

  1. Technically it would make the toolbar slightly wider, but it greatly minimizes the amount of scrolling necessary to access the necessary tools.
  2. This is true they may need to switch tabs to access the tools, but this can be minimized by thoughtful organization. And even if you are made to switch a bit, I think it'll be far superior to constantly scrolling like we are now.
  3. The top bar tabs are intended to work alongside @Brecht Van Lommel (brecht)'s proposal. Both my design and @Brecht Van Lommel (brecht)'s use the top tabs as layout presets (right?)

@Andrew Price (andrewprice), tabs for modes could be interesting but I think it'd be problematic too. There are times while sculpting that you need to bounce into Object Mode or Edit Mode while sculpting in order to do certain things (like booleaning objects). If the tabs only changed the mode, and had no affect on the layout, then this would work. But then we would need/have three sets of tabs: toolbar, layout, modes. What do you think of @Brecht Van Lommel (brecht)'s proposal, mentioned above, so far as the mode switching goes?

@Jonathan Williamson (carter2422), @Campbell Barton (campbellbarton):

Good answers. Agreed that categorising is preferred over scrolling. Essential tools are left out of the toolbar currently (e.g. bevel)

And yes, I think we can reference other apps.
Anyway, the presented mockup looks a bit like this:

I see how tool-tabs can work alongside the idea of taps at the top. And I agree that key to making it work well is well-though out organization.

@Campbell Barton (campbellbarton),

The idea to place commands in different tabs is great!
Now I'll dare to reference other 3d app. It starts from "L" ;) They have a great idea of letting users add their own tabs and associate any commands to newly created tabs. It works smoothly from "Preferences" (another name there). You click to create a new tab, then select it, select a command from a list of commands. When two items - new tab and a command are selected you press "Add command".
So for ex. if you want your own "transform-modify-reduce" tab (with a set of commands that you need especially) and it fits your own daily workflow then you get it and all will be placed exactly according to the idea of your layout. It's the main profit of this way to organize UI.
Any addons that will be enabled can be automatically added to Addons tab.
Flexibility is the main Blender's feature. That's why I'm talking about this idea.

@William Reynish (billrey),

I've worked in Modo for some time (made few sets of renders for our project). All I've got about Modo's interface... It's "slow". The organization is great but
if I compare it to Blender's current UI (no shortcuts, no contrib addons enabled) then Blender has about 1.5 times faster access (it's my inner feeling of that).
I've remembered all often used commands in Blender and now need no time to search them. Modo is great at 1st time because you understand most of the commands as you see them. After I've remembered Modo's commands positions I've realized that these big icons only take a lot of space and tabs are needed to make this newbie friendly UI possible to not take too much screen space.

If you are thinking in design a tab API to customize Blender, maybe would be a good point to implement a "Pin" function for any tab. For example, if you have several tabs, you could pin some of them and in any situation the tab is "maximized". You could mininize some tabs and keep others maximized or if you open an addon, the tab "addons" is active and the "pin" tabs keep the same position and size.

I'm not sure if my explanation is clear enough, but my idea is more or less the same you have in Eclipse or Visual Studio IDE, where you can "pin" a tab and hold open all the time.

@Andrew Price (andrewprice),

If you select a tab and go to the mode (slupting ta>go sclupt mode) there is a problem, maybe the user want to look for smething and it's annoying to change mode. But your idea has one good point, why not add in all tabs a button (small and in one corner) that means "go to this mode", if you selecct the buton in edit tab, go to edit, object tab, go to objecct mode, etc.

This button will be equal in all tabs, so for the user would be very easy to "learn" the use of this button, and we will keep a clean UI and avoid the annoying "select tab ->go to mode automatically"

@Antonio Vazquez (antoniov) think conflating tabs and modes is not really that helpful.

Currently you go into a mode and the toolbar related to that mode.

IMHO its backwards to change this so you see a bunch of irrelevant toolbars that allow you to enter the mode that they would be useful in.

If mode switching needs to be made more easily accessible or clearer to the user, IMHO this should be treated as separate issue.

@Campbell Barton (campbellbarton), @Antonio Vazquez (antoniov), agreed. Mode switching clarity is a separate issue and one that I think is greatly improved with this:

If addon developers can add their own tabs, I can see it being abused in the same way as it is today. Instead of having a long list of panels, you'd have a long list of tabs, some with large names (eg. "Suicidator City Generator"). I think tabs should be user customizable (rename, pin, reorder, hide/show, move panels between tabs) to really prevent abuse.

IMHO, the best solution to toolbar abuse would be to expand the Python API. Let addons create new editors, modes, property panel sections, etc. This would naturally spread addons over the UI. It would take a ton of work though, not something for 2.70.

I think some sort form tabs in the toolbar are indeed inevitable, panels and scrolling can only get you so far. Things like the "rigid body tools" don't make sense in the main object tab, that should be in a physics simulation tab, and there's a lot more that can be in the toolbar.

@Campbell Barton (campbellbarton): from a technical perspective, I guess tabs makes sense as a new thing UI element python can register along with panels, menus and headers? With a poll function to show/hide depending on e.g. the mode. I don't know if it needs a draw function too, a static title text (and icon) could be enough.

@Diego Gangl (januz), you're right that addons being able to create tab categories could be abused, but if you look at the existing addon categories you'll find that the great majority of addons fit nicely into existing categories. I think we'll find the same to be true of tab categories. Yes it can be abused. Yes it can become too much with too many tabs, but for the majority of the time I don't believe that'll be a problem. Most addons are not so advanced as the Suicidator City Generator that they would need their own tab.

As developers and maintainers, we can also take it onto ourselves to encourage addon authors to use existing tab categories when appropriate. If an addon abuses the system too much then it doesn't need to be approved for inclusion in trunk (if submitted in the first place).

All that said, extending the Python API to allow new modes, editors, etc is a great target and is something that has already been talked about at length. But as you say, from my understanding, it's a ton of work and so is likely a ways out.

@Brecht Van Lommel (brecht), re implementation - we could discuss details in IRC.

From checking the code and writing quick test, I'm thinking of having tabs more on the UI level of scrollbars (though not in view2d),
handle drawing in ED_region_panels() so any region that draws panels can (optionally) have tabs too.

each panel just has a string for its tab name, and ED_region_panels() manages filtering and displaying the right panels (as well as pinning) ...

This way theres just an optional field bl_category, in each panel, which is used to populate the possible tabs at any moment in time (mode/context etc).

There are some details to work out...

  • What happens when some panels have no bl_category and others do? (Probably we try avoid this situation)
  • where is the active tab stored? (assume in the region)
  • ... but you would want different active tabs for different modes? (Having some mode-tab mapping stored in the region seems reasonable solution)
  • How do we want tabs to scroll? - With the panel or stay fixed in place?

Maybe theres some better way too... this is just one way that seemed like it can work.

Alternatively this could be implemented as a button type and then panels can check some value in their poll function. both methods have pros and cons...

@Antonio Vazquez (antoniov), pinning tabs is a good idea. If you need something to be in the place without "jumping" there from another tab, I think it's ideal.

Guys, are you not taking seriously the idea about letting users to "edit" tabs?
It can be non-destructible. Letting to change something in main tabs will be restricted to "hide" option in Preferences. But newly created tabs will allow to add any commands there. It will let avoid situations when any long named addon like "Suicidator City Generator" takes too much space because it will not be in a tab's name (by default). All "abuse cases" will be virtually solved by this freedom.
The number of max. additional tabs can be fixed if this can cause a problem. Many artists will be thankful if you'll let them decide how to organize own tab space.

@Campbell Barton (campbellbarton), yeah, best to do that technical discussion elsewhere.

@Moolah Nasreddin (moolah), some customization could be done, but it would be for users to organize things the way they like, not to solve abuse cases. If an addon is poorly designed that should be fixed in the addon, not by the user. User editable toolbars are pretty much agreed to be useful, but that is off topic here, this design task is about making a better organization of builtin toolbars. If you have proposals for user editable toolbars you can put them on the wiki.

Thanks for the feedback everyone. We are moving forward with the vertical tabs for toolbars (and possibly other regions if appropriate).

Implement Vertical Tabs T37601

I see you made a decision to code, i still want to comment.
I thought the picture by andrewprice looked good.
A horizontal tab with icons like the Properties editor.

So i made this.
This scripts divides the tools with an enum of icons.
You can run it from the text editor to test.

I was thinking about a similar solution to what @koil (koilz) proposes. The idea of vertical text still bug me. But instead of putting it in the tools panel, I would put it above all panels.

This would also make the GUI more consistent - we would have similar solution in the toolbar and in the Properties window.
Something like this i guess, to replace the panels.

@koil (koilz), I don't mind this kind of thing, but there's a few key downsides when compared to the tabs system that's already in progress:

  • Reorganizing icon buttons is unlikely to be available (it could be but this would not be at all clear to the user, whereas tabs are expected to be movable)
  • Icon buttons are unfriendly to addons (and many current tools) as they require an icon to work, tabs can have text, icon, or both.

But it also has a few advantages over the tabs:

  • Uses less space
  • Using multiple rows allows for almost unlimited numbers of sections (not a good idea to have lots, but possibility is there)

One more thing. The icon buttons, like we use for Properties, define distinctly different sets of properties. Whereas the tabs are an organizational scheme within an area for tools that all apply to the same mode of the active object. I think it's good to have this distinction. Doing so also provides the option of adding tabs to properties as well (which may very well happen). So you could use tabs to better organize some properties that are currently overly long. But if we went with the icon buttons in place of tabs you would not be able to do this in a nice way since they'd be doubled up. Icon buttons within icon buttons. Not nice.

Either way, let's see how the tabs go, we can always revisit if needed.

koil (koilz) added a comment.EditedNov 24 2013, 10:20 PM

I removed my comments.

I still fail to see how this is better than ack-err's proposal. Tools were organized and labelled, and you didn't need to tilt your head to read the text. You could also hide some if there were too many.
Ultimately if there was too much scrolling an auto-collapse option could be implemented. Essentially making it work like an accordion.

Anyways, tabs are a useful UI element so no harm implementing them. Let's see how they go.

@Brecht Van Lommel (brecht),
Thanks! I got it! Sorry for the off-topic.
Yeah, of course any bad design of an addon is a matter of it's author.

More thinking about tabs:

In general I think they are essential as a way to distinguish tab-controls from radio buttons. In the Properties header, the tabs look exactly like radio buttons elsewhere in Blender. This is confusing because it makes it look like a setting, rather than simply a list of tabs.

It's also a useful metaphor that is easy to understand.

If combined with the right categories and organization it can do two things:

  • clean up the toolbar list
  • allow for additional tools to be placed in the toolbar
  • better accommodate add-ons by giving them their own tabs

However, as the mockup from @Paweł Łyczkowski (plyczkowski) shows, improved categorization, visual design and layout also helps immensely.

Question: what to do with toolbars in other editors?

Currently, only the 3D View has a toolbar. But there are many tools in the UV Editor, and all the other editors have tools too.

Do we want to put a toolbar into each editor? That'd take up a lot of extra space, unless we make sure to design it in a way that makes it very slim, or makes it possible to work in confined space (icon only?).

@William Reynish (billrey), most of the editors have toolbars (including the UV Editor). However, there's some weird mixing of them, where some toolbars have properties and some properties bars have tools. Also the position (left, right) is reversed in some cases. This really ought to be worked on as well, through a separate task.

I think that we should work to make the toolbar compatible with all editors. I believe it already is, for the most part.

@Jonathan Williamson (carter2422): The UV Editor does not really have a toolbar. It has a Properties area and a Scopes area. The scopes area is confusingly invoked with the T-key, but it's a histogram, not a toolbar. It doesn't have an area with a list of tools and access to their settings.

I don't really think it's unrelated to look at the role of the toolbar, because the organisation of it depends on it being clearly defined. But you could say that it's a deeper issue which must be solved in a deeper manner.

Here are some thoughts based on other apps:

An app like Wings is completely context sensitive. It only ever shows which tools are relevant in the current mode of operation (Item, Vertex, Edge, Face)

Other apps, such as modo, shows all tools in a list of different categories:

Silo has no real catogories other than modeling, selection and UV: In silp, it's more like a tool shelf for often used tools.

This begs the question: what is the goal of the toolbar?
Should it be a mostly complete list of tools? Or only a small subset that are often-used? And if it's only a subset, how do users find the rest of the tools in an easy way? And then, what to do with toolbars in other editors aside from the 3D View? Add toolbars everywhere? Or a single toolbar to rule them all? Or no toolbar at all? These questions are unclear. And it's quite a deep issue in search of a deeper solution.

I've thought of a few options to explore:

  • Keep the toolbar solely inside the 3D View (as-is)
    • Means you can't access it in the other editors
    • If you have multiple 3D Views, you often end up with multiple toolbars which is kinda stupid :)
  • Add toolbars to all Editors
    • That would take up an enormous amount of space on the screen if each editor would loose a good portion of their UI to a toolbar
    • Adds lots of visual clutter and disturbance
  • Implement One Toolbar to Rule Them All (ie put toolbar in separate editor)
    • Can act on any editor so you don't need a myriad of individual toolbars
    • But how do we determine which editor is in focus - ie which one receives the command?
    • This would conflict with the cursor-dependent area focus we have in Blender currently.
  • Replace toolbar with a popup (radial menus?)
    • Takes up no space when you don't need it
    • Would easily work in all editors
    • Could make tools more context sensitive this way
    • How would we fit all our tools in here?
    • Less discoverable, but could perhaps be mapped to Space, so you only need to learn one key?
    • One could still keep a tiny icon-driven tool-shelf for often used tools

@William Reynish (billrey) - About implement one toolbar to rule them all, i investigated it a bit posting over BA, then run out of time and haven't got it finished. It's addressing what you listed here:


It could potentially not brake context sensitivity, still need deeper thinking and solving, but i will go further once i have a bit more time and post a proposal on wiki.

Check this post which summarize a bit the idea of global toolbars i proposed.

Note: i'm aware this is quite big change and not reasonable candidate for 2.70. Will add to wiki for further design.

On the topic of global bars, something like that is also being discussed for the redo panel here:}
The biggest challenge with global bars is proper context switching.

@Diego Gangl (januz): The Tool Settings / redo panel is actually already global, so there's no conflict in context for that.

@Marco G (marcog): Yes, something like an 'active' editor is needed for the tools to be separated out.

This still raises some issues:

What happens when the user maximises the view? Does the toolbar then disappear?
You then have to remember to click in the correct editor first before selecting a tool.

Global redo panel is great idea but I don't consider global toolbar as good solution at all. Imho we can lose more than win.

Changing context is everything in this concept. And I can't see good way to trigger that changes in global toolbar. In redo panel, using some operator can trigger to change its context, user can learn that behavior queckly after few operations.
But how to explain users that they have to change some toggle button or press some key to get related tools in another editor window? Quite hard for me.

Mose-over focusing will simply don't work. If we have A-editor between toolbar and B-editor we work on, then mouse traveling will change toolbar to show A-editor.

Changes like that alter entire whole program workflow. Will be great if someone do working prototype few months before 2.8 release but now we better focus on changes that can be done for in near future.

Marco G (marcog) added a comment.EditedDec 2 2013, 3:14 PM

@William Reynish (billrey) - i don't know how much we can discuss this here, i don't want to derail to a bigger task which is not appropriate for the current task. If you're interested you may want to quote the post on BA i linked before and we can discuss there maybe?

Consider reading carefully what i posted, editors would be still non-blocking and context sensitive, without activation needed, the user works as now but if you want to show the toolbar of a particular editor you go with mouse over and press for example "T" such as now for toolbar. You will still be able to hover your mouse on another editor and press a shortcut to do something, toolbars won't switch unless you want it, pressing the proper key (in my examples the T).

Can't see the issue you raise, seems straightforward to me, it could be that the toolbar is automatic switching if you maximize (since you may want to get access to the tools of the maximized editor), or even not...just when you maximize, if you need the relative toolbars you press "T". Harder to explain than how it would work though.

@Bartosz Moniewski (monio):

Mouse-over focusing will simply don't work [...]

You missed a big part of the proposal, obviously it won't change automatically just with mouse over -____-

@William Reynish (billrey) I know, but the proposed topbar (for redo) has editor specific parts too.

The wiki has discussion pages, maybe it's better to discuss large proposals there so we don't go off topic in tasks.

Hmm vertical tabs and horizontal tabs both have their place. Making use of both can significantly improve usability. Example:


@DataDay (DataDay),
domonauts will punish you for this :D
Generally it's good... Vertical and horizontal tabs together are good.
But if I'll criticize your example:
M, S, R - are way too big. Need to be smaller, like one of these squares. Three buttons as sectors of a circle can be good. Or three vertical sectors of a square.
Or it must be removable - nobody needs this forever (OK, people without keyboards need it actually... but it's another story).
Addons take different width... What's your idea about it?

@William Reynish (billrey)
"if you have multiple 3D Views, you often end up with multiple toolbars which is kinda stupid :)"
It's not so stupid when it can be disabled by "T". So I think that Tool Shelves will be hideable. It make sense.
Keeping it just in one window is stupid for some concrete pipelines: example is a case when you have Blender's window divided by two areas (in a moment). One is for Front, another is for a Side view. You need them both and need to be able to click on the same buttons in different areas often.
Toolbars in all editors - yes, hideable - yes. This is my position. Everything will be in proper places.

@DataDay (DataDay),
your idea will fail here (what I've wrote just now). Only vertical tabs will be good with a vertical Tool Shelf and so on.

@DataDay (DataDay), I had to delete your mockup because it contains UI elements copied from other 3D applications. We can't have such things on official Blender websites or use them as reference for development because of copyright reasons. We have to create mockups from scratch or based on things that are licensed compatible with Blender.

@Moolah Nasreddin (moolah), I was specifically pointing to how a combination of vertical and horizontal tabs can be used, nothing more nothing less. It's an older mockup btw. I disagree with your assessment regarding horizontal tabs, but they are entirely context sensitive depending on location and content.

@Brecht Van Lommel (brecht), I see so no reference images may be uploaded? Seems odd but I can understand the need for such precautions.

@DataDay (DataDay), depends on what you mean by reference images, it's about the copyright of the material. There are exceptions (fair use etc.), but using copyrighted material in mockups or design documents is something we should avoid.

@DataDay (DataDay),
I've didn't write anything that tells "it's wrong" about those (upper side I suppose) horizontal tabs. Probably you were misguided by my weird English by some way :)
(plz, make a sketch of your mockup or my comment will be just for you, Brecht and some ppl who possibly 've seen it. Maybe you'll need it further)
Horizontal tabs are good. Obviously they need some "partially hiding" algorithm for cases when an area is being stretched. Plus arrows for scrolling.
Every clever feature is cool when it's properly designed and fits all other neighboring features. Obvious :)

EDIT - moved post into (T37601):

@Campbell Barton (campbellbarton),

Looking good so far! I don't know if you're looking for feedback just yet, so I'll wait on specifics. But in answer to your thought on "or just always have tabs", it's hard to say just yet, but I suspect it'll work well to hide the tab area when there's no tabs. Since tabs are created by the existence of panels being assigned to a category, then it should work. The only reason to always show tabs is if we have customizable user tabs, but that gets into a whole new area that is beyond this discussion.

on the topic of running out of space with tabs, a possible solution to the "too many tabs" scenario is having tabs automatically resize themselves (get narrower) when space is running out. Chrome among other web browser already does that. Also scrolling on top of the tab area allows users to switch between tabs quickly (sort of an alt-tab behavior). Try opening a lot of tabs in chrome. When you cant read the text, simply start scrolling with your mouse wheel when the cursor above the tabs.

@Todor Imreorov (blurymind),

re: "having tabs automatically resize themselves (get narrower)"

This is how vertical tabs already behave.

I know this is a work in progress, but the tabs/panels in edit mode:

Can we break the "mesh tools" panel into separate panels. It will make pinning more useful.
Repeat especially would be useful in it's own panel which we can pin. But the same applies for the others- as there is still too much scrolling down in the "basics" tab.

One can break it up a bit if they were separate panels:
transform + deform+Repeat -->transform tab
add+remove+Repeat --> add/remove tab
Normals+Shading --> shading tab
UV mapping + grease pencil--> UV/Grease pencil tab (at the bottom)

I'm not sure if this is the best tab organisation but it's the first that I can come up on the top of my head.
It's too bad this customization can only be done in code. Is there any plans to make the tabs customisable in the future?

You can break up the Add primitive panel into different primitive type panels, instead of having all primitive types in one panel. Break them up to give tabs even more meaning.
It will make panel pinning more useful imo.

In any case- great work so far. This is shaping up to be pretty awesome!

@Jonathan Williamson (carter2422) - Seeing the newly created "History" panel (great idea btw!), I would suggest putting the history list itself into this tab, without needing to click once more on "Undo history". There will probably be very few buttons here anyways, so there should be enough space.

hewi added a subscriber: hewi.Jan 8 2014, 2:43 AM

If all tools in the toolbar would have an icon (like in the create tab),
it would be easy to safe safe to be better used in the 3d viewport.
beginners could keep the toolbar wider open to see the text too.

Maybe this little video helps to explain what I mean:

The scope of this task seems too wide, where there are many opinions without much in the way of conclusions or resolution on topics.
More like a forum thread.

@Jonathan Williamson (carter2422), if this can't be used to give us some conclusion for tasks we can act on, suggest to archive it.
Tasks with a more narrow scope can be opened, and reference this one if its useful.

Agreed @Campbell Barton (campbellbarton), better to make more specific tasks in future (note to self).