"Topbar" Tabs
Closed, ArchivedPublic

Description

"Topbar" Tabs

The idea of this patch is to implement tabs as easy accessible and nicely integrated UI elements making it possible to add them to the (hopefully) upcoming Topbar (and places like the text or image editors).

Tab integration

Tabs are drawn as a new button type called 'TAB' what makes it also possible to create tabs everywhere in the UI. The button type 'TAB' allows the following interactions:

  • Selecting
  • Adding
  • Deleting
  • Styling -WIP (90%)-
  • Renaming
  • Ordering (Drag & Drop) -WIP (5%)-

To limit the needed space, a '...' tab was created. If space gets rare, some tabs are moved into a menu under it.

Look at this gif to see how it reacts when the window is resized:

The idea behind it

This Patch aims to act as a part of Brecht's UI top bar proposal:

(more here)

It also allows the integration to other Editors (e.g. Text Editor, UV/Image Editor, User Preferences, etc.).
Therefore, this patch does also include a new python UI template.

Python integration

The actual integration in the UI can happen like this:

template_tabs(data, property, new="", unlink="")

This creates the tabs, adds a "new" operator tab, assigns the delete function to the tab's 'x' icon and checks if some tabs need to be moved
under a '...' tab.

The Patch:

Details

Type
Patch

Nice patch, keep up the work!

My 2 cents:

I'm concerned about the "x" button. Its use is to unlink something (here: a screen layout), but it looks like a non-destructive action (close a tab). I would rather want a "Close" option in a right-click menu. Tablet users should be able to open the context menu with a tap-and-hold gesture. It would make it less easy to accidentially remove something, and the user could click anywhere on a tab for fast screen switching.

The "+" button should open a menu and let you do multiple things:

  • Add a new, blank screen (Info area + 3D View, basically the 3D View Full. Only a 3D View in case the Info area will become non-closable in a future version)
  • Add a new screen, derived from current (current behavior of "+")
  • Add individual default screens as they ship with Blender (factory settings), or maybe from startup.blend, it would make it easy for the user to "restore" the known screens in .blend which don't have them (e.g. .blends from other users with customized screens)
  • Maybe append a screen from any .blend file, this menu option would open a file selector

Or should there always be default screens, that can't be closed? They should be taken from the startup.blend, so every user can define a custom set (s)he always wants to see. Is it a bad idea? Less flexibility, but more consistency.

Nice work!

I agree about the "x" button, it would be too easy to lose screen layouts this way, it's not a common operation like closing a tab in a web browser. I also agree that the + button should eventually become a menu where you can do multiple things. The ideas proposed above would be nice though I wouldn't make them a requirement for an initial implementation.

Awesome!
Will you keep the blender version/scene information bar in the panel though? It is quite wide.

One way of keeping it still visible at all time is by moving it to the actual window decoration name.

Sorry for being so quiet recently. Had some problems with Ubuntu after upgrading so I spent days on trying to get a new Blender build running (it really seemed like some higher powers tried to keep me away from coding :D).
Anyway...
I'll be back in the next few days with some nice updates to the patch.

Back to work now!
Cheers

very nice!, I assume this will include moving the render engine selection to the render tab of the properties editor?
That would make more info header room as well as being more logical placement.

The tab's should work well for the properties editor tabs - except that they take up more space.Perhaps you could consider a closer spacing? I don't think the extra padding between tabs is necessary, I haven't observed other tab interfaces using it.

Sorry, I do not understand. We hide the four elements of menu in a button to save space. And show nine (and more) items from the list. Where will display information about the scene and memory?

The scene stats should be moved to another location to be honest, or there could just be a button in the info bar to open a popup. In many UI proposals, they are shown as text overlay in the 3D View (either of the corners), that's definately another good place, although some othe editors may need to overlay it as well (e.g. UV editor I guess?).

The advantage of having a dedicated popup or menu would be, that additional features could be added. For instance, Tris, Quads and Ngons could be counted individually and buttons provided to quickly select them (Select by Number of Sides operator).

This is looking really good @Julian Eisel (Severin). I also agree with the comments from @Brecht Van Lommel (brecht) and @codemanx on the X and + button functionalities.

Styling
For consistency I feel the styling should follow the toolbar tabs exactly. These should probably even be brought together in some way to create re-usable tab styling code to ensure consistency across all current and future tabs.

Scene Info/Stats
Like @codemanx said, the scene stats really ought to be moved. They're quite convenient in the header, but take up far too much valuable space. Seems to me they make the most since in the Scene properties Scene panel.

@lopata (lopataasdf) The goal is to make the interaction with the different screen layouts much easier and faster. However, you’re right that using tabs instead of a menu takes much more space, but there are ways to minimize this.
It looks like the whole Info Bar will be reorganized to be much more useful.

Look at this proposal by Brecht:


Or at this (really nice) mockup from Plyczkowski:

This is the idea that I’m trying to follow. The implementation of the tabs is just one big step for that and even if it gets accepted by the community, I don’t think it will be implemented before the rest of the reorganization is done.

@Jonathan Williamson (carter2422):

Tab styling
I tried to copy the style of the toolbar tabs as much as possible, but had to size them up a bit to arrange them nicely to the other buttons in the Info Header. Well, looking at some of the mockups, I see that the most of them are using a very different design approach. This is why I don’t want to spend too much time with the design, currently.

Scene Info, Render Engine menu etc.
I really think it’s time to open a new task to discuss the new Top Bar. This is not the right place for this (shall I do this?).

“+”, ”x” Buttons
I agree with your arguments but I think moving the delete button to RMB-context-menu would make it just another “Blender Mysterious Easter Egg”. I’ve already implemented a possible solution that would solve this but don’t want to show it, yet ;).
The “+” menu would be really cool, I’m definitely going to take a look at this.

Patch update coming really soon! I’m just cleaning it up a bit.

Thank you all for your feedback. I’m having a lot of fun with this project!

And here comes the Update…

The Patch:

Some major changes:

  • Selection is working!!
  • Implemented “…” tab. Only shown when needed otherwise “+” tab is shown.
    (Icon can still be changed)
  • Scaled tabs a bit down
  • Clicking on the "x" (only in the active tab) opens this popup:

More Screenshots:


Looking Good So far. I personally would like to see Toolbars that separate from main ui. With bigger Icons and maybe a color palette that also separates for blender paint mode and maybe the properties panel and or all panels for that matter. and more than twenty layers would be over the top. Anyways keep up the Good work. Peace

An idea for the TOP SHELF (layout tabs):

in messiah studio top tabs are not only tabs, but also buttons that bring down menus:
http://youtu.be/VsGa1ulR8Ok?t=4m44s

Using this design in Blender could possibly allow us to move the Menus out of the bottom panel of the 3d viewport.

But then we run into a problem. The custom layouts in blender are way more flexible than Messiah studio- where the layout is predetermined always.
So copying this design would be somewhat complicated, since we need to also tell blender which menu, from which layout window to draw when right clicking on the tab. That might be the active window's menus?

This can potentially clean up the interface quite a bit. Imagine multiple window layout with all of the menus hidden inside the Layout's tab.

@Todor Imreorov (blurymind): Even though this would be a nice way to remove the menu buttons from the headers, I think it would be better to leave them where they are. Moving them under tabs would just hide them, making it hard to discover them.
But I think there are cases where tabs should be able to open menus. One is the "..." tab:

To all:
I've been much to quiet again, so I'll give you all a quick update:
Not much has been done since the last patch, mainly some smaller fixes. I failed to implement drag & drop for tabs :( but there's still one idea left (would be a tough task and has to wait for now).
One thing that is still left is the ability to pin tabs. This would prevent the tab from being moved to the "..." menu.

All in all, the tabs seem to be usable, now. I would now like to start implementing the rest of the new top bar and finish the tabs after this has been done.

Thanks all :)

If only one day blender would look like the Plyczkowski mockup :)

Through I would love to get rid of the scroll to death issue in the properties panel.

Julian Eisel (Severin) renamed this task from Implement Tabs as standard UI elements to "Topbar" Tabs.Jul 2 2014, 3:28 PM
Julian Eisel (Severin) updated the task description. (Show Details)

@Todor Imreorov (blurymind) I don't think this is a good idea. I believe it makes the tabs too complicated. It would require squeezing in the name, the menu, and the close button. Even if the close option was in the context menu, I think it'd cause too much of a discovery problem.

And good stuff @Julian Eisel (Severin). Keep it up, I'm going to try and test your work soon.

Thanks @Jonathan Williamson (carter2422), but keep in mind while testing that there are still some issues left in these patches. I'll finish it soon!

Why not close tabs by middle mouse button like on the web. Easier then finding a small X button anyway.

@Vlad Mafteiu Scai (00Ghz):
As @codemanx mentioned above, "closing" a tab isn't the same as in a browser in this case. If you close a tab in a browser, it just closes the website and you can still get back to it. "Closing" a tab in in our case means that a screen layout is deleted and you can't get it back anymore. So better not use MMB here!

Of course but you could change that. Make it like in the materials section where you got a list saved even if you remove a material(which for a stupid UX reason you can't remove items from it). So MMB will work as close instead of delete.

Approach like that introduce whole new level ow complication. Code-wise and in user experience. And this task is about simplicity. Where to put selection menu for adding closed tabs? Another interface item hard to explain? How to delete layout instead of closing it? Where user should click to duplicate layout and how to tell him that this is separate data and not another tab with same layout?

Also you can remove data from material selection list. Press shift while clicking X and material will have zero users.

Update from August 3rd UI Meeting

This was discussed during today's meeting. Agreement was reached that this is going in a good direction but takes up too much space. Let's put these tabs on hold pending further changes to the whole top bar.

@Julian Eisel (Severin) if you'd like to experiment a bit, perhaps start looking at ways to implement more of @Brecht Van Lommel (brecht)'s whole top bar design?

@Jonathan Williamson (carter2422) I already started implementing the top bar a while ago. The problem is, that blender's UI code is really not suited for stuff like that (global regions, fixed horizontal layouts, etc.). After all I think I'm now able to solve these problems and finish implementing it. I'll let you hear once i've got usable results.

@Julian Eisel (Severin), did you ever get a chance to experiment with Brecht's top bar design?

Jonathan Williamson (carter2422) lowered the priority of this task from Normal to Low.Sep 18 2014, 10:17 PM

Yeah, I spent a lot of time on this again (including rewriting the topbar tabs patch), but the results aren't that promising, yet.

The most problematic is the global region we'd need to use here, but I promise you, I won't give up on this ;)

That looks like progress!

The global area is quite tricky, as it's very much dependent on the current window.

Julian Eisel (Severin) closed this task as Archived.Oct 5 2017, 6:29 PM

Oh the memories, my first Blender patch!

A few things have changed since then regarding this task & patch:

So, task & patch here seem redundant. So closing this finally :) Thanks all!