Implement Vertical Tabs for Toolbars and other regions #37601
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
30 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#37601
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?
Vertical Toolbar Tabs - solution for #37418
The proposal for vertical tabs in the toolbar has been accepted and is in development. @brecht and @ideasman42 will coordinate technical implementation, @JonathanWilliamson will review user implementation.
NOTE: ignore
panel_categories.diffattached here, they should be removed!Changed status to: 'Open'
Added subscribers: @JonathanWilliamson, @brecht, @AndrewPrice, @billrey
Added subscriber: @koilz
This comment was removed by @koilz
Hey @koilz,
The problem with horizontal tabs (even icon-only tabs) within a vertical toolbar is that we're severely limited in space. This already a problem at times in the Properties windows.
One of the reasons to go vertical, beyond the space issues, is also that they play nice with the horizontal tabs for layout switching that have also been proposed by @brecht via http://wiki.blender.org/index.php?title=Dev:Ref/Proposals/UI/Top_Bar_Reshuffle
In addition, icon-only tabs are only good so long as there's icons for each tab. With the planned implementation, addon developers will also be able to define their own tabs. Currently addon devs cannot add new icons via python, and so they're limited to simply reusing existing icons. This comes with it's own problems.
Added subscriber: @antoniov
@JonathanWilliamson The idea of @brecht for tabs is great, but there is one point that it's not clear for me: "Message area". Now the messages appears one second and you must look in the top area to see it. Sometimes, the error message is so fast that you are a lot of time thinking where was the problem, then you realized there was an error.
Could you include in your design proposal any type of list (combobox) to expand the messages in a friendly way, or better, maybe a window with the messages like Eclipse does (info, warnings and errors filter). The idea is: you have a combobox, and pressing something you get a message window.
@antoniov, unless I'm misunderstanding you the messages issue is related to @brecht's proposal, including the top layout tabs. That's not related to this task. Discussion should go on #37450 or even better, as a proposal in the wiki.
@JonathanWilliamson, sorry, it was my fault, I'm new in Phabricator and make these mistakes. You are right, I think is better a proposal in the wiki, I'm going to prepare something about this message area.
Added subscriber: @BartekMoniewski
Are toolbar tabs will be separate python files? I propose to do so. Will be easier to create custom tabs files and put them to specific sub-folder in \scripts\startup\bl_ui. Or maybe even simpler path like "user_interface" folder in "2.7x" folders.
Moved patch to D75
Added subscriber: @xrg
@BartekMoniewski - files can be split up how we like, I dont think theres any API restriction thats imposed which means a tab should get its own file, but we may want to do this in some cases too.
Added subscriber: @WarrenBahler
Added subscriber: @PawelLyczkowski-1
Added subscriber: @liquidape
Added subscriber: @Januz
Added subscriber: @DataDay
Just a suggestion (see picture) on tab style, perhaps naming and some general ideas to make vertical tabs a bit more wide spread along the interface.
Some suggestions for more conventional naming could be "Create" instead of Add, there could be a "modify" which is the general edit mesh type of tools (merge verts, grid fill, extrude...ect) or add additional modifiers with presets, Instead of physics "simulation" or "dynamics".
Also to note, if removing scrolling is part of the equation, adding sub tabs might be worth investigating. This can separate what is being added, such as nurbs/curves, primitives, lights and even joints for rigging. Plug-in creators who add functionality or things to "add" can have their own sub-tab within that category. Naturally this will offer better organization and categorization at the cost of more "clicks", but it would remove the scrolling and hunting behavior tied with the toolbar as is. Just an idea to play with.
I also tried to convey how the same vertical tabs can be used alongside the outliner, giving it a layer panel in another tab. This can be more focused on general paint and perhaps sculpting layers, or depending on how its presented render layers as well.
Again these are just some ideas to play with, they may not be perfect. =)
Please excuse the rushed job at assembling the mockup.
Added subscribers: @ideasman42, @acall
@ideasman42, @brecht, @JonathanWilliamson
Your mockup of generating vertical tabs with Python looks great.
It easily and gracefully accomplishes the goal of not taking away valuable horizontal space for the toolbars.
In the following analysis, a slight change is proposed that could make vertical tabs even better.
rotated text in vertical tab
https://drive.google.com/file/d/0B0lOujESl3X0NXBmTW5wZ1Vxbm8/edit?usp=sharing
Perform experiment #1
Perform experiment #2
Now starting with the rotated text in vertical tab mockup, I have morphed into a stacked text in vertical tab mockup using LibreOffice Draw.
Potentially this is a little easier on the eyes as illustrated in the experiments below.
stacked text in vertical tab
https://drive.google.com/file/d/0B0lOujESl3X0M3Y3N0RfNjBZc00/edit?usp=sharing
Perform experiment #3
Perform experiment #4
contrast rotated text vs. stacked text in vertical tab
https://drive.google.com/file/d/0B0lOujESl3X0dlp4SnktaW9ldFU/edit?usp=sharing
After performing the experiments a few times, the stacked text alternative seems slightly easier on my eyes. Your experience may be different!
rotated vertical text
stacked vertical text
pros
cons
What do you think? Am I barking up the wrong tree? Is this possible in Python?
Added subscriber: @JoseMariaRichardsonRebellodeAndrade
@acall I was thinking just that (stacked vertical text). Definitely easier to read. However, with your mock up It looks uglier to me. Don't know if it's just the font you chose, though.
Added subscriber: @EjnarBrendsdal
@acall: I must admit I do not agree on the stacked vertical text being easier to read.
Imo it is ver yunatural to read the letters rotated to read horisontal lines of text and then have to read the next letter under the previous one.
The whole idea of tabs are very interesting though and I guess we can risk to see some trial error development here.
@JoseMariaRichardsonRebellodeAndrade
You might have a point on the font being uglier. I just chose it because it was blockier (i.e., more squarish). I also had trouble matching the background shading of the selected tab using only LibreOffice draw. The shade of grey does not match and it does not totally cover the whole tab.
I''ll mess around with other fonts and try to match the selected tab background better.
Added subscriber: @kwk-2
@brecht, @ideasman42, @JonathanWilliamson, @JoseMariaRichardsonRebellodeAndrade, @EjnarBrendsdal, and others...
Ok, I have updated the stacked font mockup to better match the horizontal toolbar font.
Rotated text font vs. Stacked text font in vertical tabs
https://drive.google.com/file/d/0B0lOujESl3X0bUhCWl9sWEUyM0U/edit?usp=sharing
Maybe the above comparison will raise the discussion level as to which is better.
Best regards...Archie
Text based on the latin alphabet is intended to be read from left to right, so glyphs are designed to flow one into another horizontally. It's really hard to make stacked text look good, usually you can convert it to uppercase (which has more uniform proportions) but even then you have to tweak sizes of individual characters to make it flow nicely from top to bottom.
I think Blender uses Droid Sans through the UI.
Added subscriber: @hewi
I'm sure it's been mentioned before, but what about icons instead of vertical wording? Seems it would be the ideal solution, no?
Also is there plans for an icon only version of the toolbar contents?
Sorry if this has been asked a dozen times. Not sure which task the main discussion is in.
@AndrewPrice - its an option and in-fact fairly simple to do.
DISCLAIMER: I didnt choose to use text over icons to begin with.
Minor downside is...
I find it hard to articulate why I prefer text in this case though. but will try:
We use icons already for properties-space.
Icons work well for nouns, (world/material/mesh/constraint) - its quite direct you click on the icon for a data-type to see its properties.
With groups of adjectives I think the association with a picture isn't so direct.
The icon might include...
I would expect if we use icons we get a mix of this, which IMHO will give a more confusing interface.
Am sure someone with more designer experience can rationalize this stuff better :)
@AndrewPrice, I think @ideasman42 highlighted the key problems with icon-only tabs in this case. Normally I would also suggest icons for tabs, as they can be very easy to read, quick to recognize, and don't have the problems that vertical text inherently has.
In the end, I think icons work great for single items, such as a specific tool, but they don't work so well for groups of associated items. You can see this in many other apps as well. For example, Photoshop uses icons in the toolbar for specific tools (and the sub-tools), but for groups of related items they use text, generally in the form of menus.
My preference is to work towards tabbed toolbars with icons for tools, but text for grouping.
@acall You do make a good point, but I don't think it works better with stacked text. I thought it maybe would, but it doesn't. Also, I realized this week that Maya (which I have to use for work), has vertical tabs with rotated text and I had never questioned it. So, although your effort is perfectly understandable and appreciated, personally, I don't think it would work better.
@JoseMariaRichardsonRebellodeAndrade
Thanks for the comment. I did find an even better font called "Source Code Pro" which is mono sized in both horizontal and vertical directions.
For now I'll just set this thought aside and maybe the idea will come up again by someone else.
Added subscriber: @Lockal
Added subscriber: @plasmasolutions
Added subscriber: @samvila
Would be nice if we could have custom tabs in the same way that Maya has the shelf menu where you can drag your favorite tools into your own tab. I think there's a GSOC this year that they had something like that and it was VERY interesting. Maybe is time to bring that code into 2.70.
@samvila, most of us agree this is something we need, and is indeed at least partially addressed in the GSOC. But that's a separate task than this. The custom toolbar/tabs/ will be discussed more once the GSOC project is able to be reviewed more.
Added subscriber: @Bollebib
I wanted to give feedback to this possible new addition as proposed by Campbel Barton (and team?)
Apparently this is now the place to post feedback (unless I'm mistaken)
The tabs seem great and I welcome them.
You mention in that video on blendernation, that you might need to set the pinbutton elsewhere.
Why not just hide the icon by default and:
1)hover on a single panel area to show it.
2)on a pinned tab the pin should be visible.
An extra way would be to provide a shortcut to pin/unpin (don't forget a tooltip in this case!)
other then that I want to press on you 2 vital areas which are in my opion crucial to make this work.
Provide a default,yes but let the user ,the END-user (not only by coding!) customize it as they want:
it should be able to:
I stress this because there will be no one way to please everyone.
Just provide a way to reset toolshelves to default easily via a shortcut (don't forget the tooltip!) or any other way and you should be foolproof.
2)Global Toolshelves
provide a UI option to have GLOBAL TOOLSHELVES. (similar to "global scenes")
This would be a way to have the SAME toolshelf (panel order,visibilty) in no matter what layout you are. It should be possible to set the toolshelf once and have it present in ALL views.
I don't discount the current way of doing which stores a hundred and 1 different toolshelves all across the layouts,which can be fine for some.
But 'm sure plenty of people also just want to set it once and propagate it everywhere without having to think about it anymore.
These are my 2 cents
kind regards
@Bollebib There are multiple problems with global toolshelves due to Blender's multi-editor approach, I'm sure you'll find some discussion about this when will look around.
@PawelLyczkowski-1: I think what he means is that the toolbars are the same across all the same editors - that the items in the toolbar should not be stored per region, but per editor. This makes sense, because, if you spend time setting up the toolbar in one 3D View, you'd expect the list (but not the active tab) to be set up the same in another 3D Views.
@billrey Ah, right. Sorry @Bollebib, I didn't read carefully enough.
yes that is what I meant,sorry for being perhaps unclear
it is indeed per editor (that i feel) that the toolbars should be stored,for this option. Some people might find benefit in the current way,I'm sure,but I like to set it,and then let my muscle memory get used to always having the same setup.
The current way blender does this I just don't bother customizing it and keep the default. While that is annoying to me,it's less annoying to set it the way I want it time and time again. A comparison might be if you go to another layout and you have to re-input your custom shortcuts for every new layout.
1- I like the idea of showing the pin only on hover. It'd be better if it only came up when hovering over the panel title area. That way it's not poping up all the time while you work.
2- I would only agree with Global Toolshelves if they're optional. For some workflows you want to have different toolshelves in editors (for instance using a main 3D view to animate and another small 3D View to check how it looks from the camera).
Regarding show-on-hover, I really dont think this is good.
Hover icons can work, and I'm not totally against them in general - just don't think its really worth to introduce them for this one button alone.
If the pin icon is a little distracting IMHO its better just to use a more subtle icon, (just like how the drag area is already subtle).
I made a change to attempt this in the most recent patch - but some different design may work better.
@Bollebib, re: Customizable tabs, Id rather keep this separate from vertical tabs.
Customizations can be added to the existing tabs without so much trouble. (in fact it wont touch the new code much at all).
But I'd like to get the current patch accepted in master before making further plans.
I think customized tabs should be proposed and discussed in the context of custom toolbars, which is really a separate topic IMHO.
@ideasman42:
I agree that the pins are rather distracting. They look like they are more important than the tools inside the toolbar itself. They scream 'pin me!' and take attention away from the things that are more important. Repeated icons like this are best avoided.
I think the best solution (if it's even worth having such functionality) is if the pin icon is only visible in a pinned state, but invisible when unpinned. That way, most of the time you'd never see the pins. To pin, users can right click on a header and pin it. This is nicely general enough that we would use it for Properties panels too.
@campellbarton
In what way will you be able to customize?
(luckily the pins,if they work will help in some ways)
But what if the user doesn't agree with how you structured your vertical tabs? Will blender remember the pins,the order, if they are open or closed?
Is there a way to ONLY show pinned tabs,or to only show unpinned tabs?
Introducing tabs is fine and dandy but don't let the user feel restricted by them,as I believe this was one of the reasons why tabs were shunned in the first place (too much clicking). I might be wrong though,but it's still a concern that need to be adressed.
I personally do not think,however,that customizing the order and in which tabs ,or which tab logic you want to store your panels is the same as having a custom toolbar. A toolbar is indeed a seperate topic,this is not. It's about finding panels in a way that makes sense to the user,and that differs for everyone (but there should obviously be a good default.
I can accept if people can rearrange tabs by changing python scripts. It's not ideal,and for a program that has expanded the use of drag and drop to ridiculous,yet incredible uses,I cannot comprehend why one couldn't just drag a panel to a different tab.
But in the end I can live without it if the default is great. So I'll wait and see.
Most importantly,even without customization,global toolshelves is something that needs to be considered,as not having them will result in the same:
people just accepting the default,rather then adjusting it to their needs (and maybe having a quicker workflow because of it) ,as the latter is far too annoying.
PS:agreed that unhide on hover should not be used just for this.
@Bollebib - I rather not discuss this at all now, and when we do, Id rather check on "How really good customizable toolbar work" -- then consider tab categories as apart of the same project.
@billrey - When you want to pin, IMHO its good that its a few clicks - (2 clicks - pin and switch tabs).
Check the top icon here:
http://www.graphicall.org/ftp/ideasman42/pin.png
Probably its not the best design - but its visible while not distracting.
Id prefer not to put this behind a menu - though I can see theres not many alternatives if you consider a pin button clutter/annoyance etc - IMHO while theres not much room for buttons here, theres also not many/any others buttons we would want to add? Maybe at some point we would have a menu. but for now It would be a menu with just one item? two?
@ideasman42: I understand your rationale. But now with that pin icon it's almost invisible (but not quite), seems like a bit weak compromise.
When the toolbar becomes more useful, and it starts to actually work with tools like Transform etc, I think it's very important that it doesn't become too busy.
Also consider we might add the toolbar to other editors too. That means we quickly get loads of those pin icons everywhere. And when we have icons for tools, it's very nice to make the toolbar really slim and out of the way. A large pin icon would go against that, and would compete against the actual tool icons.
Right now, before reading 'Scale' or 'Subdivide' I see these large pin icons.
Besides, although it's a somewhat cool feature, pinning toolbars is not really that important - most users will probably never use it. If the navigation around the toolbar is sensible and well designed, you won't have to.
Rather than making the toolbar more complicated, I think we should work towards making it simpler and clearer. Remember to KISS :)
I agree with William, I think this should not show always.
A right click menu might come in handy once we have custom toolshelves, to rename, edit or remove the panel. The ctrl+click shortcut could also be in it since probably not many people know about it.
The right click menu is a good solution, and if you include "Online Manual" and "Collapse all other panels" you already have 3 items.
@ideasman42 : i guess we disagree on this account
But nonetheless I'm eager for the results.
In spite of that I still want to hear your opinion about global tool and properties shelves,as they are related . Even when there are categories,and even if they are well implemented, there will be an order to the panels,even more so when you pin them. Is there a consideration to implement a setting (or however developpers feel is best to do so) to aleviate having to make the same settings over and over? I sincerely would like to know an answer to this.
additionally I thought I somewhere saw the remark that shift or control clicking several tabs to show or hide multiple tabs underneath each other was a good idea to quickly have a good oversight to see panels of those categories together.
This would reduce necessarily having to jump back and forth for a certain task where both are quickly needed without clicking too much. It differs in an important way from pinning,as pinning is on an individual panel level.
I wondered what your thoughts were
@Januz Rightclick solution could work for that pin ,but it's hidden...Maybe a tooltip if you hover over a panel title?
you could also add
" hide and show panel" (shortcut a)
"zoom in" (shortcut +)
"zoom out" (shortcut - )
"reset zoom" (shortcut home)
I agree with the right click menu solution for pinning. That would be ideal for an uncluttered interface, but that right click needs to eventually be consistent across the entire interface in other area's as well. It also follows convention.
On that note though, might I recommend instead of having pinned tools in every tab, let them only exist in a pinned tab that exist on its own. It would not only reduce confusion but maintain a level of consistency in the tabs themselves. This also allows for a pinned tab to have further "more dynamic" development at a later date, such as loading and saving layouts or other means of customization.
We definitely need an icon. If we hide it behind yet another shortcut, it'll become another feature that users discover 4 years later by accidentally hitting the wrong key.
It needs a clearly visible button or icon.
Reason:
"If a software application hides its functionality and requires its users to recall what to do, some percentage of users will fail."
So I'm personally in favour of @ideasman42's solution of making the pin icon faded.
However, I think the pin icon demonstrated is a little unconventional. I'd go with the standard icon already in Blender:
It's simple, easy to understand and doesn't require the user to search the wiki for the shortcut.
We had a discussion about this after the sunday meeting yesterday with @ideasman42, @JonathanWilliamson, @billrey, and the decision was to put it in the right click menu. We can open a separate design task for panel header design and reconsider, but we shouldn't let this block the tabs work further.
@AndrewPrice: The idea is not to hide it behind a shortcut, but have it in a right-click menu. Yes, it's more hidden than a pin button, but if we show every option to the user all the time, we get a very crowded, convoluted UI. The pin button looks ok if just look at it isolated, but in Blender with many tool categories and toolbars coming on other regions, you'd have a lot of those pin buttons.
Other ideas were explored, such as having pin buttons appear on hover, but then you'd have these pin buttons flashing on and off as you move the cursor around the toolbar, which is also quite distracting.
The UI for the tools panels should defer to the tools and tool icons themselves. Remember what the main focus of the toolbar is: it's to contain tools! :) Things like pinning panels is a meta-level control, not a real tool, and those should to crowd the UI. In the future we'll probably have some way to define custom toolbar categories and so artists can add (drag?) tools there to make nice collections for workflows.
It's a bit like the menu you get when you right-click a header where you can flip headers. Imagine if there was a button for that: it'd get in the way, and take attention away from the real items in the headers. Likewise, with the pin button in the toolbar, it looks like a pin tool, but it's not.
As Pär Almqvist said, “A modern paradox is that it’s simpler to create complex interfaces because it’s so complex to simplify them.”
The best interface designs are invisible. They do not contain UI-bling or unnecessary elements. Instead, the necessary elements are succinct and make sense. Whenever you are thinking about adding a new feature or element to your interface, ask the question, “Does the user really need this?”
We have to do the hard work to make sure the Blender UI is simple, humane and understandable. We still have a way to go on this, to boil things down and make them essential, removing unnecessary cruft. Always when adding stuff, remember KISS, keep it simple stupid. The simple is almost always the right way to go, and the more essential the toolbar can be, the better. We keep it essential by making sure it contains toos and tool categories, organised an a beautiful and clear manner, and no other distractions.
Added subscriber: @PaulGeraskin
@billrey I like that Vertical tabs are on the left. As on your screen http://developer.blender.org/file/data/uj5olyexggssfdvipfzp/PHID-FILE-nhbq2spdq6wclfxgoloa/toolbar.jpg
This is really great. As far as I know they are on the right at present.
@AndrewPrice - we had a long discussion about this on IRC, the way I see it - this basically boils down to weather you consider pin an essential/important feature for using panels or not.
flipping the header IMHO is fine to have in an RMB menu simply because default layouts are normally setup quite well, and even if the header isnt where you might expect you can still access the header.
Pinning isnt essential to use a toolbar but you may get frusteraighted if you dont know about it for a long time with no hint the feature exists... so I dont think this is really good.
However, we can re-evaluate this once the feature is in, The pin-icon can be enabled with one line change. (I've kept it in the code)
Added subscriber: @FilipMond
It seems like I'm not a user with needs for tabs.
For me is Ctrl+Click (to collapse all at once besides the only one i'm interested) still enough.
I saw codemanx's proposal , that looks quite nice, but vertical orientation is totally new element in UI, that seems strange for now.
Maybe I need to see it in use and placed in other parts of blender's UI …
Is there any build for OSX already to test it?
Thank you
I was wondering if the vertical tabs will be optional, when the design and code is finished.
Will there be a way to switch from scroll to tabbed mode? Or will tabs replace scroll?
If each panel had a tab category, I wouldnt think it would be too hard to implement.
Please wait until you see the actual toolbar contents to judge if you need tabs, with the current toolbar you don't need tabs because it only contains a small subset of tools. We shouldn't start by adding options, let's see how this works in practice and then evaluate.
Committed
a621d1e488We could close this task and open other tickets for...
Panel categories - propose categories and tools (think this is most immediately important).
Panel header (pin button/grab/menu etc)... when we have time to review this and after panel-categories have been used a bit.
Custom Panels - more long term, the topic came up here but it should get its own ticket too IMHO (though I dont have time for it right now).
Removed subscriber: @samvila
@FilipMond, @koilz I understand some dont like mentioning other applications, and I agree there is sometimes a good reason for it. In this case however, its important to point out that nearly every major 3d creation package out there has some form of tabs, including vertical ones. The reason for this is that the software developers need to find ways to not only categorize UI elements, but keep it manageable, especially with 3d creation suites which if anything are far from being simple applications.
Thus getting used to tabs is not just a smart idea, but it will help in any transitioning to other 3d applications or vice versa. From an industry standpoint, its not a strange new idea but often an expected one. You have everything to gain and really nothing to lose by adapting to them. =)
It will increase usability.
I do like the tabs, im yet to test them, but i think they will be great.
They will be good for adding more tools to categories like animation.
And the animation tools wil be out the way when not required.
Sorry if the question was a bit misleading.
campbellbarton said: 'Panel categories - propose categories and tools (think this is most immediately important).'
carter2422 did add some design tasks, though he said these tasks were waiting for this task to be complete.
http://developer.blender.org/T37569 3D View Toolbar: Reorganize Object Mode Tools and Options.
These tasked should be listed in the desciption if they are still valid. If not i guess they should be closed.
:
The 3D View has different modes, Object, Weight Paint. I dont know if you want to limit Vertical Tabs so its only for some modes.
If this has been decided, let it be known, if not add a design task.
Animation tab will be good for Object and mabey Pose mode, but i dont think it will have much use in Edit mode.
@brecht: OK, sorry
Removed subscriber: @FilipMond
@brecht @billrey @ideasman42
Sorry my mistake, I didn't realize you were talking about a right-click menu. I thought the idea was just for right-click = pin, making it one of those mysterious hidden easter eggs.
In that case I agree that a menu is a fine solution.
Cheers!
@AndrewPrice - dont worry, we still have mysterious hidden easter eggs :D, Alt+LMB Toggles pin.
Though I've added the this to the menu so its not all that hidden.
(Though its quite possible users wont think to RMB here, so IMHO its still kindof hidden/non-obvious).
Added subscriber: @TodorImreorov
what if the pin icon shows up only when you are hovering over the panel that you want pinned and only on that panel?
This sort of a solution between being hidden in the right click menu and being everywhere.
Maybe that adds to the UI cpu consumption? Having to check if your cursor is hovering on top of a pin-able panel and then drawing the pin icon?
Some questions.
What are the currect tab categories for object mode?
I guess they are these: [Edit][Animation][Tranform][Relations][Physics]
Do the tab categories have to be designed more, or have they been decided as the above?
Are the tabs just for 3D view object mode Tools?
Should we add designs for tab categories here?..: #37569
@TodorImreorov - hovering while possible. doesn't work so well with tablets.
@koilz - current categories are undecided.
Added subscriber: @marcog
@ideasman42 - was wondering, would be possible/easy to implement the chance to switch between tabs pressing for example "Tab" while on mouse over the tollbar? Would fit well with Blender's fast workflow and lack of many clicks IMHO. Just a minor thing though.
Changed status from 'Open' to: 'Resolved'
Closing this since the tabs are finished and now it's dependent on the actual category creation and organization: #37418
I'm sorry for posting on a closed thread, but as the title is "Implement Vertical Tabs for Toolbars and other regions"
I'm just curious if its planned to extend the tabs to the properties panel as well.
personally I get lost in the properties panel more often then the toolbar, especially with all of the confusing/convoluted "display type" panels.for example, is there a clear difference between "view" and "display"? I really think tabs would make this much cleaner and accessible , grouped something like:
Active:
Camera:
Viewport:
Reference:
Layers: ?
Just a suggestion , can be improved I'm sure.
But, this probably should be another task
@WarrenBahler I also get lost in the properties panel much more than in the toolbar. Besides that, I think it's got properties that could be seen as tools.
To me, background images are more of a tool than a property (it's got properties, but it's a tool). Also, it is kind of a nuissance that you create a Grease Pencil and mess with it's properties on one side of the viewport and then you need to go to the other side to start drawing (considering not everyone knows the shortcuts). I know it is correct, but can't it all be together in the tools section? Basically, what I'm proposing is that tool properties in specific are moved to the Toolbar. It would be better for workflow, I think. With these new vertical tabs in the Toolbar, it wouldn't cramp it up that much and it would free up the properties panel a bit.
Sorry. I know it's mostly off topic, but it's got to do with the fact that with these new vertical tabs, the toolbar can now take more things that probably belong there in favor of good workflow.
@JoseMariaRichardsonRebellodeAndrade - the categories I suggested are certainly open for opinion, but as I see it, a tool is something that interacts with or affects/creates another object, while a property is an inherent value of the active object. so.. while the pencil is a tool, its properties go in the properties panel.
This is obviously not ideal in every case, with things like the background images, it wouldn't make much sense to have and "add background image" tool, and then edit its properties in another panel.
And while this is somewhat like what we do with the grease pencil,In another sense, the images could be considered a property of the view-port, while the pencil can interact with objects and modifiers as well.
i also think there is potential to extend functionality by displaying additional tabs based on the active object mode; ie. when in paint mode, a "palettes" tab could activate in the properties panel, where we could store and display paint pallets and brushes for easy access, while not crowding the tool shelve any more than it is already.
in any case, the tabs we have now should help, and hopefully they get extended to the properties panel eventually. we can only ask for so much from the already amazing and overworked devs :-)
@WarrenBahler I know it's logical, just not practical, in my view, that when you press "draw" on the toolbar you have to open the properties panel on the other side to change the color and thickness. Maybe this could appear temporarily in the bottom part of the toolbar when the grease pencil is created, as happens with some addons. I don't really have the solution.
And yeah, we really do have great devs :-) (that I hope forgive me for going completely off topic. I will stop)
@ josemaria & russcript
Because this task was closed, I have moved this discussion to:
http://blenderartists.org/forum/showthread.php?323319-Grease-Pencil-Tool-Workflow
I would appreciate your feed-back there.
Regards
Hewi
Added subscriber: @michaelknubben
I'll post this for consideration before reading the rest. So if this has been mentioned before: Sorry, I'll find out soon enough :D
In this mockup I'm showing off what could happen if you'd collapse the tool panel. Personally, I like keeping the panels out of the way, but I do find myself using them quite often, and collapsing it to only the tabs would be very useful for me.
@michaelknubben I would rotate the vertical labels 180 degrees. Other than that - looks awesome.
@michaelknubben It's very good! I only think that one should have the option to collapse the panel completely as well (including the tabs).
Plyczkowski: agreed! Bad oversight on my part, you're right.
Jose: You're right, but I'm not sure what's the nicest solution. Cycling between the three states somehow? Or dragging the border to the screen edge completely gives you the current plus sign, but stopping at the tabs gives you this?
That last one sounds pretty good to me, as long as there's a zone of a few pixels in which it snaps to the tabs-only view.
Added the change Plyczkowski suggested.
@michaelknubben I also prefer your second solution. There could be some sort area very near the tabs where if you scaled down the panel to that small area, instead of showing ridiculously small buttons, it would snap to only the tabs (and then if you carried on scaling it would eventually snap to callapsed tabs and panel, as it does at the moment).
@ideasman42 Would it be possible for the active area for the tab (the area that you click on) to extend to the window edge? Because that's where most of the clicks will go, right on the edge.
@PawelLyczkowski-1 : I believe this is what you're discussing - https:*developer.blender.org/T38171
Added the Operator Menu as a tab & cleaned the mockup a bit
About pinning behaviour - I think it would be a good thing if pinned panels stayed on top.
The reasoning behind this: the idea of pinning is to make certain panels very easy to find. But at the moment pinned panels are sometimes before all panels in a tab, and sometimes after. I guess this also means that they would sometimes be somewhere in the middle, if for instance the user, after pinning a panel, activated an addon that adds a panel. That would make finding the pinned panel in the currently active tab harder (since you don't know where it is in it) than going to it's native tab (since you know where it is in it). Making the pinned panels stay on top on the other hand would make finding the pinned panel in the active tab easy again, since you know where it is - it's on top.
Added subscriber: @Ton
There are a number of useful variations possible here - that are all interesting - but I haven't seen it summarized - or analyzed really.
Like:
Even though I personally can read vertical (rotated) text quite well, we also should acknowledge that it goes with many factors slower... you won't find rotated text in UIs for that reason. People will much better remember "the 2nd tab" or symbols here.
There was a suggestion to color code the tabs at blender artist, which I thought is quite interesting way to help users find things by colour.
I think softimage did something in those lines - although not for tabs.
Perhaps to be more subtle, you could only color the text in the tabs.
Or use a small circle icon next to each tabs name (like a dot) with a different color based on the tab.
But this begs the question of consistency in the ui. The Properties window icon tabs are quite good as is in place and size- minimalistic.
I personaly like the idea of keeping them as is, but making their button shape look a bit more like a tab. Main reason being that we have the exact same looking buttons within the properties panel and they are used as button switches. Freestyle is a great example here- some of the buttons in there are switches and some are actually tabs- they look the same. And you have tab-type buttons inside a panel! Very perculiar for blender.
One of the mockups suggested doing the toolbar in similar style tabs as the properties window tabs.
But as noted before, there are many advantages in using text style tabs for toolbar. You could move the editing mode list to the top of the toolbar panel and turn it into buttons to switch modes, which in turn change the toolbar's contents.
There is still a lot of clutter in the toolbar created by sliders and tick boxes. Some users have been mindstorming on moving those to a dedicated top bar for tool settings (similar to photoshop). This can potentially free up some horizontal space, but loose some vertical. A very thin top panel is the perfect place for sliders or buttons that bring up sliders. The reason for that is the wider a slider is, the easier it is for the user to get a specific value. Zbrush is a good example for this. It has a super thin top panel with really nice wide sliders and some switch buttons.
Do we really need constant access to sliders and tick boxes? Some software such as mypaint- focused on tablet interaction keeps the tool options hidden untill requested (by click of an icon- top shelf). Or has them easy to hide when constantly visible -the right side panel in mypaint is a good example.
Bringing back Zbrush as great example of minimalistic UI- the left click menu in zbrush (or was it the right, i forgot) brings up a brush settings dialog box where the cursor is - housing settings,sliders and toggles for the brush that is used. Clicking anywhere outside of thas dialog dismisses it.
This is great for tablet users- sculpting or texturing. Reduces greatly the effort of having to navigate to a dialog that is away from where the action is- the canvas. It pops right under your cursor. More importantly- no need to search for it. They have the exact same sliders on the top panel I mentioned- but they decided to also put them in that dialog.
This sort of design approach is being borrowed in mypaint. There you can ask a color dialog or a brush dialog to pop right under the cursor with a shortcut and it is dismissed when you click anywhere else on the canvas.
Blender currently already does that in a way- just not housing any sliders or buttons.
@Ton re: "you won't find rotated text in UIs for that reason"
Vertical text is used elsewhere, in mainstream applications even (both for similar purposes)
I was wondering which text orientation makes sense and looks good in a tabs that are on the left and on the right of the content, and I think it's the orientation in which the content of the tab is under the text. In other words, when tabs are on the left it's the counter-clockwise orientation, and when they are on the right it's the clockwise orientation.
In which case the orientations in Microsoft Visual Studio are sub-optimal. Here is a quick mockup how it would look corrected - https://dl.dropboxusercontent.com/u/6959287/Art/Blender%20UI%20Mockups/visual_studio.png
@Ton
Pros for icon headers in Properties: They take very little space. Thanks to the brilliant icons, the meaning is quite readable. Cons: It's not as readable though as a header with icon and text, which hinders discoverability. This could be improved by displaying the section title (Render, Scene etc) above the content of the section.
For the toolbar tabs, adding icons would make finding appropriate sections easier, and that is a genuine thing to solve, because we will have more tabs in the end, due to addons adding tabs. This would have a similar positive effect on finding tabs as color-coding, without looking bad (and colorful tabs would look bad, here is an example - http://screenshots.de.sftcdn.net/de/scrn/45000/45092/colorfultabs-12.jpg).
Adding icons would also solve the problem in a scenario when there is not enough space for tabs. In this scenario, instead of tabs being squashed and displaying a single letter each, the text would vanish if there wasn't enough space for example 3 letters, displaying only the icons (tabs without icons would still display text).
As for horizontal tabs, if this idea went further - https://developer.blender.org/T37450 - they could also be used for Workspaces (window layouts).
This is hard, because it means hiding/removing elements, and there usually are people that are used to these elements. William and I did some mockups on a calmer visual style (less embossing etc), that would help a bit. As for removing elements - the Object panel in the N-sidebar, item name in the header, breadcrumbs in Properties and the Transform panel in Object mode would be my candidates. As for improving the organization of the GUI, there is a lot of ideas in my mockups and my Doc.
Cam: I meant to write "won't find it much in UIs". Modo is an exception. They follow this rule:
No-scroll is nice, but look what happens for smaller windows:
{F68681}
Ton makes a good point, the mockups have been mostly visual and haven't made attempts to verbalise what's going on.
On the topic of Icons vs. Vertical Text, I am in favour of having both.
Vertical text is time-tested and to me personally quite easy to read. Nevertheless, I find icons offer an additional anchor for the eye to focus on, and might after a few glances be the primary way for the user to find the tab they're looking for, leaving the text to support this in case they need a reminder.
Icons also serve as a way to represent the tab in cases where the tabs have grown too small for text to be helpful. In this case I wouldn't display the classic elipsis (...) to indicate the text is being truncated, as that has the unfortunate side-effect of chopping off a further three letters.
Whether horizontal tabs have a place in Blender is a bigger question, and I don't know if we should artificially limit it. The Properties Window currently features what are essentially tabs, albeit styled differently. There have been suggestions to display them vertically there as well, which would solve the width-issue, but in either event I think they should be styled consistently with the tabs being suggested here.
I agree that a flatter, simplified style could be a good start for making things less chaotic, but a few good ideas have been put forward about widget-placement which we could discuss later.
Ton: Exactly, they don't use icons there, and use elipsis to indicate truncation, which in my mind is very counter-productive as it further limits the amount of useful information you display. With an icon, the worst-case scenario is that only the icon remains (we should not allow a tab to shrink further than that!).
Even plugin-added tabs should have an icon by default. The ones that don't supply one are given a standard one that identifies them as being added by a plugin (a wrench, for instance), but add-on creators should be encouraged to supply their own (the community can assist in this, it's a nice way for artists to give back to addon-creators.).
Here's a minimal styled 'tab' I saw coming by from Jens:
http://www.jensverwiebe.de/Other/tabs_alternative.jpg
It's visually a strange item now, but it does have something we shouldn't reject easily. A variation of this idea I can see it work, combined with refreshing (cleaning up) more in the UI. Also imagine:
@TodorImreorov: You can have the redo panel as a popup by pressing F6. (I think that's what you meant?)
@Ton: The issue I see with those tabs is figuring out what's inside each tab. Also, the clicking area is a little small. I like the idea of scrolling left-right. Having a button that pops up stuff that's not visible would be consistent with the behaviour of @brecht's top bar.
On Horizontal tabs: I think they would work great for the properties panel and maybe the nodes editor. (Also, the proposed top bar).
Having icons on tabs would be nice, but what about custom tabs or addons? vTabs would probably be used on other toolbars too for consistency (like the image editor in paint mode). We would need quite a few icons.
The main issue with vTabs is still this:
Icons wouldn't solve this completely, because you'd still have too little space for all of them. Maybe if tabs retained their size after a certain amount of shrinking, then the user could scroll through them. At least they would still be readable.
Actually, with icons you'd have enough space for all of those. You'd never shrink down beyond the icon ofcourse, that would just look silly and leave almost no target to click on.
@Ton,
Depending on how you meant where vertical tabs are located, at the top of my head, you can also find them in Maya and Cinema 4d to the right side of the screen. They also mix in situational horizontal tabs, though in Maya's case... in one scenario that leads to lots of scrolling until the delete history command is used. I know vertical tabs exist in far more than just 3 other major 3d applications though, they do work..and they do work well.
Thus the question would be, in what scenario would tabs be unfriendly inside of Blender. You gave one case where they are smushed in Modo.
I would argue that the problem is how people try to lay out their windows or expand on panels that conflict with the tabs. Blender faces the issue where every window is competing for space inside the UI, and nearly everything is broken down into those separate windows. They are neither combined or unified in their design, thus causing the user to play a UI layout game trying to find the right combination for what is displayed and how much space they are given. I also wonder how often users flip through preset layouts as opposed to just remaking the layout they want every time.
Anyways, this causes blender's UI to look fractured. Hotkeys, interfaces within interfaces and all that are not universal. While it opens the door for quite a few layout configurations, it not really helping speed up the workflow or be visually coherent. By its very nature, there is interface conflict, more of it than less.
One solution would be try and minimize on the number of windows with their own individual interfaces being present. They could be merged, or only present in certain layouts picked from a tab above (much in the same way we see in 3dcoat and modo). If users want to really change or tweak their own layouts to be as conflicting as they want, having a layout tab with savable presets would be the most logical choice. We really need to see some streamlining here.
If individual modes for specific tasks via layout and UI configuration can be made (seen in Brecht's drawing), then the UI designers can maximize on that space and interface so that it best suits the job at hand. Each layout can maximize and design itself around that particular task in the most effective manner.
I flip through the presets (modeling, uv-ing and animation layouts), and find them to be fantastic.
Your point about it not speeding up the workflow is silly. The interface's versatility is an asset, not a hindrance!
The fact that the default layout is entirely adjustable by the user rather than being set in stone is the power of the system, it makes it so the user isn't held down by what the Blender Foundation decides should be the defaults. If users use this to make a layout with a hundred subdivisions and slow down their workflow in the process, that's really not a concern of anyone but themselves and whomever may employ them.
@michaelknubben, you entirely misread what I typed. I didnt say the presets didnt speed up workflow, nor does it look like you understood the content of the post.
Your post seemed to imply Blender's current UI system's seperation of things into their own window is less desirable than unified, developer-led designs that are more set in stone.
If I misunderstood that, please do explain rather than only dismiss.
@michaelknubben, I didnt say desirable either. I said by the very nature of a fractured UI, more UI conflict occurs. This very task topic is a signifier of this.
Blender's approach currently has multiple windows (editors) which can be placed in any fashion all around the limited space provided by the user's display (monitor). Each window/editor, instead of being consolidated or universalized, has its own separate UI, its own set of hotkeys, and all of which is dependent upon whether or not the mouse is over it. This means that every editor has to "function" as well when squished and moved into all shapes and sizes, which then causes far more limitations in design than it does to empower the design.
The workflow then becomes less centralized on the mode/production task, and more centralized on the windows themselves. It is far better to have one menu strip for all rather than many headers with their menus taking up horizontal space, scattered across a UI.
Each editor/window also has to have its own header (top or bottom) with its own set of menus, icons, side panels...ect Rather than have a consistent area for what they are used for, due to the mouse hover = active window, it forces many aspects of that editor to be forced within the confines of that editor.
I dont think anyone can objectively argue this is a good thing or more functional. Often times we put the sentiment of being able to "customize" any and all layouts over the work centric approach. Its cool to have those options, but beyond the sentiment, the cons outweigh the good in my opinion.
Modo is a great example of how you can have custom window layouts, both popped out and inside of the display window, but also one where its design is focused more on the task and pipeline for that task. The customization of each panel is not put at the forefront, but hidden behind the default layout modes.
I'd have to agree with @DataDay in response to the mockup Ton posted. The circles leave no clues for what's inside and it's very inconsistent with the rest of the interface. Unless we're doing a complete UI redesign where we incorporate these swipe/circles then I think it's going to cause more an even steeper learning curve and more guessing by the user.
On another note, does anyone know if anything is being done with the empty 'Operator' part of the toolbar taking up nearly 50% of the space?
Shouldn't Operator be the sort of thing that hugs the buttom until it's called into action? I've never understood having it visible and in a prominent position when it's not in use. It's sort of the equivalent of a blank dialogue box.
@AndrewPrice there is discussion about the operator panel here: #37450
I tested what I believe is the current version of the vertical tabs
I have a few concerns.
1)Pinned panels are added below other panels. On top seems better to me (maybe a RMB toggle option if this is a source of strife?)
2)While shift clicking to pin panels is great there should perhaps be an extra option to Shift+click tabs or click+drag tabs (like you can do with layers and outliner) => those tabs will then show all selected tabs underneath each other
This point is the most important one,I feel.
3)there should be a few quick operations to make managing tabs and panels easier.
Most of these should probably be RMB additions.
(there might be more)
CTRL click hides all other panels but one-> maybe Double CTRL+click could do the reverse to show all other panels quickly.
a few useful keyboard shortcuts for the more used operations wouldn't be amiss
6)show the current panel operations shorcuts in the RMB! (zoom in/out , reset, hide all other panels...)
Blender needs to comunicate its functionality!
with my suggestions the RMB menu might be a bit more crowded but no more so than the Shift+A menu. Just order them well and you will give the users a useful tool to interact and discover the different functions of the tabs. If you keep them as they are,they won't be any fun to use and will lead to much clicking.
Other then that I don't really mind how it looks,horizontal or otherwise,icons or no icons. I mostly care about more functionality and giving power to the user.
Added subscriber: @nathanowen92