Reorganize 3D View Toolbar #37418
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
24 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#37418
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
Development
Changed status to: 'Open'
Added subscribers: @JonathanWilliamson, @brecht
Added subscriber: @PawelLyczkowski-1
I would advise to prioritize adding new toolbar functionality from the @ack-err GSOC before this task.
Having said that, here is my mockup with an rearranged Edit Mode toolshelf:
Such a toolshelf would boost discoverability.
The base for this toolshelf is actually coded in python. If you want to try it, or experiment with reorganizing it, you can get it here -> https://dl.dropboxusercontent.com/u/6959287/Art/Blender%20UI%20Mockups/mesh_tools_prop.py . Most of the buttons work.
The grouping could be better. No 100% logical grouping is needed though - the purpose of the grouping is mostly navigational, to provide a way to remember tool placement, and later recall it quickly.
Also, displaying a list of names left aligned boosts the ease of eye-tracking, as this old mockup by William demonstrates:
And here is an interesting, although not applicable, icon only toolshelf:
Added subscriber: @ack-err
There is also the summer of code work by @ack-err. It's my plan to get that reviewed on a design and code level in the next months, so this hopefully ends up being one of the bigger topics we can tackle since it's already under development, though I think it will likely be for the version after 2.70.
Added subscriber: @CodeManX
Added subscriber: @billrey
@PawelLyczkowski-1: Why is it not applicable to have an icon-only version? With a design such as yours, it could auto-detect when the toolbar is too narrow to display the full words, and the switch to using only icons.
@billrey Yeah, but the toolbar also contains addons, so below (or above) the nice icon-only toolshelf we would have a messy column of squashed addon panels.
It could be displayed when the toolbar would be closed though - then the toolbar would display only the toolshelf icons, in a MMB button scrollable manner for smaller screens. I like this idea.
Added subscriber: @Januz
Ack-err's proposal included popup panels. Addon panels could be reduced to icons and show the popup on click.
Each addon could declare an icon in bl_info (or get a default)
As for Add-ons, they could just provide an icon?
@Januz @billrey That would be ideal, but at the moment there is no way to add icons to add-ons. I'll ask if this is a feasible idea for a design task.
@billrey @PawelLyczkowski-1 that makes sense to me, to make addons define a custom icon (once we're able), or if no icon is defined then use a default one to show it's an addon.
@JonathanWilliamson:
Makes sense, yes
@PawelLyczkowski-1:
Your mockups with more sensible organisation show how much improved organization and clear icons help navigate the tools. It's way clearer than the current tool shelf.
@billrey Thanks.
@PawelLyczkowski-1: One comment though: The titles are currently centre-aligned, which hampers vertical eye-scanning somewhat. Might be nice to make them left-aligned instead.
@billrey Yup, agreed.
What I wonder about with these designs is:
We don't want to break all the addons, right? I thought it would be left untouched - scrolling and closing panels, with additions from the GSOC like the ability to popup panels.
I would say only vertical, with the ability to drop tools on a horizontal bar (that's also GSOC), preferably in the form of floating icons. That would allow users to add quick access to some obscure operators they personally use often.
Along with the customizable horizontal bar I would only add the ability to hide and show panels.
@brecht I think I'd like to see that kind of thing (more customized toolbars) done as a separate task. We should be able to reorganize the current one, and add a bit more functionality (like icon only) without affecting the actual toolbar location, or behavior.
Unless there's opposition I'd like to go ahead and move forward with the below proposal:
And then possibly:
Aside from the icon-only support, this should be pretty trivial and works nicely with future work too (like (un)dockable panels) but will also be a great step up from the current version. The icon-only support has some issues, such as what to do with buttons that have no icon? But I think this is solvable.
@brecht: Good points. Well, we should aim for as little scrolling as possible, but if a user's screen is tiny there's only so much you can do. One thing we could do is this:
When the toolbar is wide, you get to see all the titles, but if it is narrow, you get to see only the icons (with titles on hover). Saves space.
Horzontal vs vertical: Vertical lists are easier to scan down, because western languages are left-to-right. Having a horizontal version could be ok, but in the end it's more work, more cases to account for etc, so not convinced that it is worth it.
Customizability: This is a good question. Some way to put often-used tools in some tool pane is useful. The question is, should that be the main toolbar? Or should be put a different area below it that is user-customizable?
The advantage of having them split up is that you can rely on the main toolbar to stay the same, and you can do layouts with multiple columns. In @PawelLyczkowski-1's mockup it's nice that tools are in two columns to fit them all on the screen. On the other hand, it might get confusing with multiple tool areas, and how would they compete for screen space.
I guess it's conceptually simpler to have a single toolbar that you can then customize rather than having two. But I'd prioritize having a nicely laid out toolbar to having one that's poorly laid out and customizable.
@JonathanWilliamson: 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, 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 @PawelLyczkowski-1'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.
Added subscriber: @AndrewPrice
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.
@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.
@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.
@Carter-10 2422
We could make the toolshelf icon-only without making the toolbar thinner - just put more in a row.
@PawelLyczkowski-1 @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: http://developer.blender.org/file/data/hfr75ap64dqeq5pbwc3l/PHID-FILE-73rymiqvfvz6fxbqtxxm/justbuttons.jpg
Added subscriber: @antoniov
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: http://developer.android.com/design/style/iconography.html
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
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:
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.
Added subscribers: @all, @moolah
@JonathanWilliamson,
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 :)
@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.
@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: 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.
Added subscriber: @AnthonyEdlin
@CodeManX,
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...
Added subscriber: @BartekMoniewski
@JonathanWilliamson 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.
Thoughts?
Added subscriber: @ZsoltStefan
@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.
@ZsoltStefan 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.
@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 @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.
@PawelLyczkowski-1,
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.
@AndrewPrice, like @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.
Added subscriber: @ideasman42
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 @ideasman42, for Toolbar tabs (and layout tabs, but these can be ignored for now):
http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Tab-Interface#UI_Proposal:_Tabbed_Interface_for_Screen_Layouts_and_Toolbar
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.
@JonathanWilliamson 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.
@JonathanWilliamson 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?
@PawelLyczkowski-1
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.
@PawelLyczkowski-1, 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).
@AndrewPrice, Tabs could change mode but think it would be better not to, only be a view on the toolbar.
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).
@JonathanWilliamson: Interesting idea regarding tabs. But it's not really clear how this will help.
For example:
How would this fit with the idea of having tabs in the main header of Blender as @AndrewPrice and @brecht have both suggested?
@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
@billrey,
@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's proposal, mentioned above, so far as the mode switching goes? http://wiki.blender.org/index.php?title=Dev:Ref/Proposals/UI/Top_Bar_Reshuffle
@JonathanWilliamson, @ideasman42:
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: http://www.youtube.com/watch?v=5YkT0ODDvkw
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.
@ideasman42,
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.
@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.
@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"
@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.
@ideasman42, @antoniov, agreed. Mode switching clarity is a separate issue and one that I think is greatly improved with this: http://developer.blender.org/T37450#20
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.
@ideasman42: 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.
@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, 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...
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...
@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.
Added subscriber: @alexjf
@ideasman42, yeah, best to do that technical discussion elsewhere.
@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 #37601
Added subscriber: @koilz
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.
Picture: http://www.pasteall.org/pic/63062
Script: http://www.pasteall.org/47586/python
You can run it from the text editor to test.
I was thinking about a similar solution to what @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.
http://www.pasteall.org/pic/63066
Something like this i guess, to replace the panels.
@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:
But it also has a few advantages over the tabs:
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.
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,
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:
However, as the mockup from @PawelLyczkowski-1 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?).
@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.
@JonathanWilliamson: 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) http://icculus.org/~lucasw/Wings3D/move_normal.PNG
Other apps, such as modo, shows all tools in a list of different categories: http://features.cgsociety.org/stories/2004_9/luxology/def_layout_large.jpg
Silo has no real catogories other than modeling, selection and UV: http://www.cartographersguild.com/attachments/3d-modeling-objects-maps/21624d1264891901-cs4-extended-plus-silo-3d-silo-screenshot.jpg 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:
Added subscriber: @marcog
@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.
http://www.blenderartists.org/forum/showthread.php?298932-Blender-UI-Mockups-and-Ideas-Requested&p=2500684&viewfull=1#post2500684
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: http://developer.blender.org/T37450#20}
The biggest challenge with global bars is proper context switching.
@Januz: The Tool Settings / redo panel is actually already global, so there's no conflict in context for that.
@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.
@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.
@BartekMoniewski:
You missed a big part of the proposal, obviously it won't change automatically just with mouse over -____-
@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.
Added subscriber: @DataDay
Hmm vertical tabs and horizontal tabs both have their place. Making use of both can significantly improve usability. Example:
{F36100}
@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?
@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,
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, 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, 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, I see so no reference images may be uploaded? Seems odd but I can understand the need for such precautions.
@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,
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 (#37601):
@ideasman42,
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.
Added subscriber: @TodorImreorov
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.
@TodorImreorov,
re: "having tabs automatically resize themselves (get narrower)"
This is how vertical tabs already behave.
Added subscriber: @xrg
Added subscriber: @Bollebib
Added subscriber: @ionarn
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!
@JonathanWilliamson - 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.
Added subscriber: @hewi
Added subscriber: @KarlKuhberger
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:
toolshelf_icons.mov
Added subscriber: @mont29
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.
@JonathanWilliamson, 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.
Changed status from 'Open' to: 'Archived'
Agreed @ideasman42, better to make more specific tasks in future (note to self).