Noticed there are some unwanted changes caused by merges (related to linking & transform orientations mainly). Please ignore, will remove them soon.

I know this is a work in progress and not finished at all, but I'll leave a few unsolicited suggestions if I may; purely from a mere user point of view:

The order of the buttons, pulldown menus, tools etc should try to roughly reflect some sort of hierarchy, like say:
Scene Selector Pulldown Menu > Layers Pulldown Menu > Interaction Mode Pulldown Menu > Operator tools properties
On the top header next to the tabs if possible keep only the ones that may not fit into the same hierarchy like Render Engine selection and Screen Layout which are transversal to all.

Other than that this is looking pretty good, especially if the eliminates the need for that temporary operator properties on the bottom left of the Tool Shelf; it is always wrongly sized and easy to miss.
Would also love if you brought back the old behavior of popping by default the operator properties pop-up directly in the 3D View, like in the old days of pre-2.49.

Sorry for the noise, keep up the great work.

Some UI design notes from testing this:

• The operator redo properties look messy. The roundness of number buttons, lack of clear grouping, .. . Some tweaks will be needed here.
• I think the second bar in the top bar should be higher, I expect that would look better and distinguish it more from other area headers.
• I hope we can move the render engine menu into the Render menu, once we hopefully have draw modes in the 3D views again.
• The screen layouts menu could be made smaller, leaving out the screen name? Maybe screens don't need names anymore.
• Scene and render layer menus should probably be in the same bar?

Thanks for the quick review @Brecht Van Lommel (brecht)!

In D2758#64986, @Brecht Van Lommel (brecht) wrote:

Would be good to see the to do items, there's a bunch incomplete/glitchy stuff I could list in reviewing this that you are probably aware of.

Indeed, I should really write down the to-do items. I'm on a little vacation the next few days, so not sure if I'll find the time. Will definitely try to.

Probably there should be 2.8 tasks created here to track to do's.

Not sure if that's really needed, I can just list them here. I think most are rather quick to resolve anyway. Not against it, just wondering if this wouldn't be overkill.

In D2758#65001, @Brecht Van Lommel (brecht) wrote:

• The operator redo properties look messy. The roundness of number buttons, lack of clear grouping, .. . Some tweaks will be needed here.
• I think the second bar in the top bar should be higher, I expect that would look better and distinguish it more from other area headers.
• I hope we can move the render engine menu into the Render menu, once we hopefully have draw modes in the 3D views again.

Agree with all of these.

• The screen layouts menu could be made smaller, leaving out the screen name? Maybe screens don't need names anymore.

Yes, I hope we can get rid of user visible names for screen-layouts as well. We could give it a try once 2.8 is more usable and ready for serious testing.

• Scene and render layer menus should probably be in the same bar?

The upper bar contains global/scene/window properties right now, while the lower one contains per-workspace properties and the operator redo settings. I think that's a reasonable separation.
The scene is per window and the active render-layer per workspace currently, so having both in the same bar would break that separation.

In D2758#64985, @Duarte Farrajota Ramos (duarteframos) wrote:

The order of the buttons, pulldown menus, tools etc should try to roughly reflect some sort of hierarchy, like say:
Scene Selector Pulldown Menu > Layers Pulldown Menu > Interaction Mode Pulldown Menu > Operator tools properties
On the top header next to the tabs if possible keep only the ones that may not fit into the same hierarchy like Render Engine selection and Screen Layout which are transversal to all.

There actually is some hierarchy in the current alignment of items:

• The first bar contains items that are global/per-window/per-scene. The Blender icon-button and the menus are global, the workspace tabs and the scene switch are per window. The render engine menu is supposed to be moved to the render-layer settings or at least into the properties editor to my knowledge, so its current position is just temporary.
• The lower bar contains per-workspace settings (object mode, screen-layout, render-layer) and the global last operator settings.

So the hierarchy is that the upper bar contains items that are not per workspace, the lower bar per workspace ones. The last operator settings are an exception to this rule because of space usage, but think this exception is fine.
I guess this hierarchy becomes more clear and makes more sense when using it. I'd expect this to be the best or most reasonable structure, but maybe others disagree :)

Would also love if you brought back the old behavior of popping by default the operator properties pop-up directly in the 3D View, like in the old days of pre-2.49.

Not sure which exact behavior your referring to here, but I don't think we're going to do something like this soon. We have our non-overlapping UI paradigm currently, which I'm quite happy about. However, sounds like something an add-on could do.

Thanks for the feedback :)

In D2758#65044, @Galen Beals (galenb) wrote:

Excellent! Looks really great.

If I may add too: The tabs replicate the function of the layouts menu. It seems like there only needs to me a way to remove layouts and you're good to go with just tabs. couldn't You easily get rid of the layout menu and gain some space?

The tabs actually represent workspaces, which are new in 2.8. They are there for configuring Blender for different workflows within a project (modelling, animating, rendering, compositing, ...). Previously, that kinda was the purpose of screen-layouts, but workspaces go much further than they do.
We figured there is still a need for multiple screen-layouts within those workspaces. So actually, each workspace can contain it's own list of screen-layouts now. That's why there are both, workspace tabs and the screen-layout switch.

General Note

I notice we start having some general UI design discussion here. Of course that's fine, but we should move it to T50845. That way we can stick to the code side of things here :)

Question on terminology:
So far we used the term "screen" to describe everything visible in the window. That was fine since - except of popups - everything was part of the screen-layout which is represented by bScreen.
Now we have global bars that are part of the window contents, but not part of the screen-layout. What term are we going to use for window contents (= screen-layouts + global bars + popups)? Sticking to "screen" could cause confusion with bScreen.
However, bScreen could become deprecated by moving all of its data to workspaces and workspace-layouts (which are a wrapper around bScreen currently). We still had to keep the struct for versioning, but the term "screen" would be less confusing then. Would still require some work though :S
Note that this term would be used a lot in code. It better be good!

facade, theater, deck

I'm not sure what the new term is needed for, isn't the workspace the window contents? Is there some data structure that this window contents would correspond to?

In D2758#67301, @ronan ducluzeau (zeauro) wrote:

facade, theater, deck

IIRC JavaFX uses "Scene" for window contents but obviously that isn't an option for us. The window itself, they call "Stage" which sounds good to me. I'd just prefer something that's a bit more self explanatory, but doubt we'll find anything perfect.

In D2758#67304, @Brecht Van Lommel (brecht) wrote:

I'm not sure what the new term is needed for, isn't the workspace the window contents? Is there some data structure that this window contents would correspond to?

Well the workspace is kind of the same as screen-layout in this context, but the top and status bars are not part of the workspace (in terms of code design). Neither are popups but they are neglectable.

There is no data structure for the window contents yet, although we could add one to clarify API where needed.
The issue appears in cases where we need to separate the layout part of the window from the reset. E.g. at some places we need the window pixel count including global bars, sometimes without it. Current code:

int WM_window_pixels_x(const wmWindow *win)
{
	float f = GHOST_GetNativePixelSize(win->ghostwin);
	
	return (int)(f * (float)win->sizex);
}
int WM_window_pixels_y(const wmWindow *win)
{
	float f = GHOST_GetNativePixelSize(win->ghostwin);
	
	return (int)(f * (float)win->sizey);
}

/**
 * Get the total pixels that are usable by the screen-layouts, excluding global areas.
 */
int WM_window_screen_pixels_x(const wmWindow *win)
{
	return WM_window_pixels_x(win);
}
int WM_window_screen_pixels_y(const wmWindow *win)
{
	short screen_size_y = WM_window_pixels_y(win);

	for (ScrArea *sa = win->global_areas.first; sa; sa = sa->next) {
		screen_size_y -= sa->winy;
	}

	return screen_size_y;
}

Naming isn't really clear here and needs the comment (or code) to clarify.

The term "screen" currently doesn't have a clear scope. Does it only refer to the screen-layout? Or does it also include the global bars? It's mixed currently.

From that code example, I don't see why you need new terminology to describe the full window, that part seems unambiguous? It's the smaller subset that might not be so clear, perhaps that can be called "workspace size" if the workspace only covers that part.

Having a hard time explaining my issue :S
I guess the actual ambiguous term is "Screen". Up until now, it was our term for window contents. That made sense because the screen-layout aka bScreen was the only window content (neglecting popups). Now we have global bars that are not part of bScreen. Yet we still use "screen" as highest level entity or for window contents, e.g. SCREEN_OT_userpref_show, ED_screen_animation_play, screen/ folder (that also contains global bar code), ScrArea (also used for global bars), ...

Here's two things we could do:

• Deprecate bScreen by moving its contents to WorkSpace and WorkSpaceLayout (a current bScreen wrapper). Keep using term "Screen" for entire window content, meaning we don't have to rename things all over in code. For code only affecting layout we can use "workspace-layout" or so.
• Introduce a new name for window content, e.g. "Window-Stage" or short "stage". Function, folder and struct names would have to be changed. DNA structs like ScrArea would have to be versioned since they don't support renaming I guess (or simply ignore?).

I think we should ideally rename things instead of having some halfway solution. "Window", "workspace" and "workspace layout" seem quite understandable to me, and "screen" seems no longer useful.

Current screen operators could get WM_ or WORKSPACE_ prefixes as appropriate, the screen/ folder could be renamed to workspace/ (even if it contains code for a bit more of the window). Perhaps ScrArea could be renamed to WindowArea, though that would require some DNA trickery and may not be worth it.

I still don't get why you need a term like "window stage" though, why not just "window"? For users additional terminology doesn't seem that helpful, and for the code there doesn't seem to be a need for a corresponding data structure.

In D2758#67312, @Brecht Van Lommel (brecht) wrote:

I still don't get why you need a term like "window stage" though, why not just "window"? For users additional terminology doesn't seem that helpful, and for the code there doesn't seem to be a need for a corresponding data structure.

I would say we have an object-oriented (well, actually struct-oriented) API naming approach, which I think works quite well. And I don't think we should break it here. When I read "window" in Blender source, I relate that to wmWindow.
This "window" we talk about is not part of of WM though, it's probably just ED. So I find the term misleading. Maybe I'm overly picky here, but I'd still suggest a term that separates the roles better. So I'd still vote for something like "window-stage". Or maybe "editor-stage" fits even better.

As for an own data-structure, right, it's not really needed. But having one might make thinks easier to understand still. Using "editor-stage", the ED_stage API (currently ED_screen) and it's operators (e.g. STAGE_OT_userpref_show) would have a data-structure to refer to, say EditorStage.

When I read "window" in Blender source, I relate that to wmWindow.

And I think that's fine and don't think there's a need to make a distinction, but I'll leave the decision to you.

Do you remember them? :-)

During the 90s, websites were sometimes created using... iFrames.

When I look at a Blender window:

... I see "frames", I see something really similar.
(btw, when I hover a "editor button", a tooltip informs me that you call them "areas").

For me a "window" means: "what is contained inside the whole software (all toolbars, viewports, menus, panels, etc... everything).

_ my 2 cents.

In D2758#68102, @Sergey Sharybin (sergey) wrote:

Just did quick tests of a branch and here is some issues:

• Top bar is almost totally empty by default, without any indication whether anything will ever appear in there and what is it all used for.

We could place various things there - recent files list, "Show Splash" button, Help button... or nothing at all. Either way, it's a design issue, nothing important for an "Initial Implementation"

• Vertical alignment is broken.

What do you mean by that? It should not be possible to align the top-bar vertically. Maybe in future, but not now.

• With the factory startup, move the cube, tweak vector in the top bar and you will get convertViewVec: called in an invalid context.

From TODO list in patch description:
"Solve context issues with operator settings (e.g. changing settings after translate prints errors to console)."

• All operator options in a single line doesn't read easily at all. There is also More button even when all properties are visible.

We need to get D2883 merged so we can address this completely. Although we also need to update operators to use it which is quite some monkey work...

• Default motion tracking layout is totally useless with the operator redo moved to top bar. Try moving marker in this file and then use re-do panel.

That seems like a bug. I'm pretty sure it's caused by the same context issue mentioned above though.
Maybe we'll have to temporarily set context to the state the operator was initially executed in. Although ideally operator exec wouldn't depend on context... needs investigation.

Also I'm actually not sure why I didn't remove the redo panel in the clip editor tool-shelf yet. Will do that soon.

• Try adding new marker and see how useless redo panel in top bar is.

That too looks like a bug. Need to check what's going on there.

I think before raising question whether it's fine to merge or not, interface should be brought to a state when it's attracting attention and does not scare people away from being unpolished/confusing. It should really be 100% clear.

What speaks against developing this further in 2.8 branch? I mean, other patches are merged early-on as well, and development happens in blender2.8. E.g. Clay, Eevee (started out as black 3D view iirc), tool-system, manipulators, depsgraph CoW, etc. As an example tool-system and manipulators have many open issues & bugs too, but that's fine since work is still ongoing. Why would top-bar be different?
Also note that I'd like to get D2883 merged first, so topbar could support this right away (making the settings of commonly used operators far less scary on first sight).

We could place various things there - recent files list, "Show Splash" button, Help button... or nothing at all. Either way, it's a design issue, nothing important for an "Initial Implementation"

Design is crucial to be made before implementing anything in code.

What do you mean by that? It should not be possible to align the top-bar vertically. Maybe in future, but not now.

This is what i mean:

Compare that to vertical alignment in Space Info in master. In topbar branch space above the ID selectors is bigger than the space below.

From TODO list in patch description:
"Solve context issues with operator settings (e.g. changing settings after translate prints errors to console)."

Can you elaborate on how you plan to solve those?

What speaks against developing this further in 2.8 branch? I mean, other patches are merged early-on as well, and development happens in blender2.8. E.g. Clay, Eevee (started out as black 3D view iirc), tool-system, manipulators, depsgraph CoW, etc. As an example tool-system and manipulators have many open issues & bugs too, but that's fine since work is still ongoing. Why would top-bar be different?

All the projects you listed are either self-contained modules which never interfered with rest of Blender from the beginning, or had long story in a branch before design was fully locked, or are hidden under command line argument. Topbar is an interface feature, which must be clear for artists (who are already using 2.8 branch). That clarity i don't currently feel or see. Also, I can accept some known issues/todos under the hood, but first code should work according to a design spec.

There is another bug.

Move the monkey, switch the scene, tweak vector in top bar.

In D2758#68135, @Sergey Sharybin (sergey) wrote:

We could place various things there - recent files list, "Show Splash" button, Help button... or nothing at all. Either way, it's a design issue, nothing important for an "Initial Implementation"

Design is crucial to be made before implementing anything in code.

While I do agree this question needs to be answered, it doesn't matter much for this patch IMHO. It deals with much bigger issues (mainly supporting global areas that aren't part of the customizable layout). And this one doesn't seem crucial at all for me. We have our core design since months, it hasn't changed much since then and it's what I started implementing here.

Note that I also opened a design task for the last missing design bits, T53139.

What do you mean by that? It should not be possible to align the top-bar vertically. Maybe in future, but not now.

This is what i mean:

Ah! You're speaking of button alignment within the topbar.
Noticed this before but never found the cause of it... Did some general corrections to top-bar size calculations and committed workaround for the alignment itself (rB08258f92e4e8c407).

Compare that to vertical alignment in Space Info in master. In topbar branch space above the ID selectors is bigger than the space below.

From TODO list in patch description:
"Solve context issues with operator settings (e.g. changing settings after translate prints errors to console)."

Can you elaborate on how you plan to solve those?

I did fix them in the meanwhile by temporarily resetting context to the state the operator was executed in. See rB815eebbe17ab632.
Actually a similar trick was already there to support region dependent operators in quad-view and the like.

There is another bug.

topbar_scene.blend586 KBDownload

Move the monkey, switch the scene, tweak vector in top bar.

This was actually an issue in blender2.8. Fixed with rB03f1b94e02388.

What speaks against developing this further in 2.8 branch? I mean, other patches are merged early-on as well, and development happens in blender2.8. E.g. Clay, Eevee (started out as black 3D view iirc), tool-system, manipulators, depsgraph CoW, etc. As an example tool-system and manipulators have many open issues & bugs too, but that's fine since work is still ongoing. Why would top-bar be different?

All the projects you listed are either self-contained modules which never interfered with rest of Blender from the beginning, or had long story in a branch before design was fully locked, or are hidden under command line argument. Topbar is an interface feature, which must be clear for artists (who are already using 2.8 branch). That clarity i don't currently feel or see. Also, I can accept some known issues/todos under the hood, but first code should work according to a design spec.

Well, then take layers/collections as an example, none of your mentioned points apply to it. But I don't want to waste our time with such discussions on principles. Just wondering why this project would be handled differently from others.

When I say I'd like to try to merge this patch, for me it means addressing issues found in the review process to the point that people in charge accept the changes and merging it only then.
So I've addressed the issues you mentioned (except empty top-bar on startup which needs a design decision, and the ones requiring D2883). Let me know if you find more.

In D2758#68102, @Sergey Sharybin (sergey) wrote:

• With the factory startup, move the cube, tweak vector in the top bar and you will get convertViewVec: called in an invalid context.

• Default motion tracking layout is totally useless with the operator redo moved to top bar. Try moving marker in this file and then use re-do panel.

These are both the same issue. Fixed in rB815eebbe17ab632.

motrack.blend575 KBDownload

• Try adding new marker and see how useless redo panel in top bar is.

Issue was with operator-macros which I thought would work fine. Fixed in rBd6ca724a0e5779.

Also removed redo panel from Clip editor (rB85f7ed1aa80617).

Surely developers see it clearer than me, but I personally find several blind spots in the design of the top bar. Sorry in advance if I'm confused.

I throw some doubts and reflections:

1. What attributes will show the top bar, the tools, or the last action performed?

The actions that take the position of the cursor when executed as move, extrude or bevel ... do not allow to comfortably access the toolbar during its execution to modify a parameter. There will be a problem similar to what we now have when the action is launched from the tool panel.
The tools are adjusted before or while they are used, while the parameters of the action are adjusted after applying the action. I understand that a temporary modal tool, show its attributes in the toolbar hiding those of the last action, but if the tool is permanent, as the active tools of the latest versions of Blender, I believe that generates conflicts.

2. Are paint and sculpting paintbrushes considered tools or modes?

In my opinion they are tools with many attributes, and these atributes should be in the top bar. Having six atributes in the top bar and the rest in the floating menu of advanced options I see it a bit ridiculous for some tools. For this reason in the image below I show the options distributed in panels inside the topbar.

3. What will be shown in the Left Side Panel, once we have the top bar?

Actually it shows a mixture of buttons to execute actions, properties of tools and options of tools, depending on the mode and the shelf in which we are.

4. Mode is global or by area?

If I have not misunderstood, in version 2.8 the mode will be global, and I can not imagine it without the existence of an active area, since it often works with more than one area on the screen.

In D2758#68546, @Albert (wevon) wrote:

Surely developers...

Answered you in the design task here: https://developer.blender.org/T50845#469789 This task is more for specific patch stuff, the design task is for general design discussion.