Global Top-Bar - Initial Implementation
Needs ReviewPublic

Authored by Julian Eisel (Severin) on Jul 29 2017, 9:17 PM.

Details

Summary

Global Top-Bar - Initial Implementation

This adds the initial implementation of the new global top-bar, as decided on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Global_Bars).

Main Features/Changes for Users

  • Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
  • Upper sub-bar contains global menus (File, Edit, etc.), tabs for workspaces, render engine and scene selector.
  • Lower sub-bar contains object mode selector, operator redo buttons, screen-layout and render-layer selector.
  • Individual sections of the topbar are individually scrollable.
  • Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
  • Top Bar should scale nicely with DPI.

Technical Features/Changes

  • Support for global areas (horizontal-only for now). They are part of the window, not part of the screen-layout.
  • Removes all info editors when reading old files, they'll get an entirely new purpose
  • New space-type "Top Bar". (Shouldn't be selectabe through menu - see TODOs)

TODO

Feature-wise:

  • Split operator settings into basic and advanced settings. (D2883)
  • Add "More" button to top-bar for advanced operator settings.
  • Show buttons for operator settings while using modal operators.
  • Add a way to hide the top-bar (needs discussion on if we want this and how it should work).
  • Add a way to delete workspaces from tabs (not directly topbar related but should be done for merge).
  • Polish operator settings buttons (better grouping, better spacing, etc).
  • Increase height of second bar to distinguish from headers.

Code-wise:

  • Disallow changing editors into topbar through UI (hide from menu) and Python.
  • Solve context issues with operator settings (e.g. changing settings after translate prints errors to console).
  • Integrate layout based regions (regions that auto resize to content bounds) a bit nicer.
  • Fix glitches with HiDPI screens. (Might be fixed now, needs confirmation)
  • Some general fixes & cleanup.

Diff Detail

Repository
rB Blender
Branch
topbar
Build Status
Buildable 933
Build 933: arc lint + arc unit

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

Julian Eisel (Severin) retitled this revision from Global Top-Bar, Initial Implementation to Global Top-Bar - Initial Implementation.Jul 29 2017, 9:58 PM
Julian Eisel (Severin) edited the summary of this revision. (Show Details)

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.

Brecht Van Lommel (brecht) requested changes to this revision.Aug 1 2017, 1:53 AM

Great to see this taking shape, seems to work pretty much as expected in my tests. 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. Probably there should be 2.8 tasks created here to track to do's.

For now only some quick code review comments. It's difficult to review some of the places where a lot of code moved. The way things fits together makes sense to me: making the top bar a new space type, that is in a new global area in the window.

source/blender/blenloader/intern/versioning_280.c
335

DPI is per window now, so this can't be correct in general. Maybe it get fixed in some later refresh anyway. I see a bunch of flickering as well when switching workspaces, clicking redo, etc. Not sure if that's a refresh issue related me using high DPI, or if there's some other layout refresh issues.

source/blender/editors/interface/interface_layout.c
3505

This doesn't seem to belong in layout code?

Regardless, I don't think the operator name should be in a button to redo the operator, I think that should be a separate button with a redo icon. Now I expect users will think this is an "apply" button, not a "redo" button.

source/blender/editors/screen/area.c
1577

Might be good to only have ED_area_initialize that checks ED_area_is_global.

2132

Not using the TH_HEADER color here at all anymore seems wrong?

source/blender/editors/screen/screen_edit.c
687–696

Can you add a comment about what this code does?

860–863

Is this really supposed to be if/else, or could both types of updates be needed? It's not very clear me what the different types of updates are, some comments might help. Or maybe some code could be deduplicated?

source/blender/makesdna/DNA_screen_types.h
427

Maybe RGN_FLAG_DYNAMIC_SIZE would better describe the intent of this flag, rather than details about the implementation?

430

It's not clear to me how this flag can work reliably. It's only read in one place, but I would expect sizex to be used in many more places that might break if DPI is applied?

source/blender/windowmanager/intern/wm_subwindow.c
248–250

These got renamed to screen but then don't use WM_window_screen_pixels_x?

This revision now requires changes to proceed.Aug 1 2017, 1:53 AM

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)!

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.

  • 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.

source/blender/blenloader/intern/versioning_280.c
335

It's indeed not correct, but we'd have to call WM_window_set_dpi or duplicate its code here to make it correct. However, the area size and coordinates are also set in screen_test_scale before drawing. So we can actually remove the code here that sets area vertices and size, it's redundant anyway (meaning we don't need dpi_fac here).

source/blender/editors/interface/interface_layout.c
3505

I'd say the entire function should be moved to interface_templates.c, doesn't belong to layout code at all if you ask me.

Re button text - For now I mostly followed the design from T50845, I guess we should discuss such things there. I definitely see your point though.

source/blender/editors/screen/area.c
1577

They used to be quite different, but now they are almost identical. So +1 after all.

2132

Right. Think that was a quick test that got committed accidentally. Will remove.

source/blender/editors/screen/screen_edit.c
860–863

The else block is basically a partial version of ED_screen_refresh that just ensures area/region sizes are updated. It's needed for the regions in the top-bar that are supposed to fit to layout size (think of layout or DPI changes).
Actually I think we could add something like bScreen.do_refresh_sizes to avoid unnecessary executions of this. Should also help making clear what this does.

source/blender/makesdna/DNA_screen_types.h
430

Other places might break, but for now it isn't an issue for us since sizex is mainly used for region resizing which isn't possible in global areas currently.
I'm not really happy about this flag in general. Would like to spend some more time on investigating if we can avoid it. For the time being I should probably add a XXX noting that this should only be a temporary solution and that it might cause issues.

source/blender/windowmanager/intern/wm_subwindow.c
248–250

Eeek right, variable should use term 'screen'.

This comment was removed by Galen Beals (galenb).

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 :)

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 :)

Julian Eisel (Severin) edited the summary of this revision. (Show Details)Oct 4 2017, 7:53 PM

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!

Julian Eisel (Severin) edited the summary of this revision. (Show Details)Oct 4 2017, 8:36 PM

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?

Julian Eisel (Severin) edited the summary of this revision. (Show Details)Oct 5 2017, 6:07 PM

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.

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.

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.

Julian Eisel (Severin) updated this revision to Diff 9456.EditedOct 23 2017, 3:14 AM
Julian Eisel (Severin) marked 16 inline comments as done.
  • Show theme options for tabs in UserPrefs
  • Remove redundant setting of area size; Add comments
  • Fix touchpad scrolling not working in topbar
  • Add 'x' icon to active workspace tab to delete workspace
  • Fix small jumps of area rectangles and contents
  • Remove ED_area_global_initialize
  • Don't show redo buttons in top-bar if redo is not supported
  • Rework tab data storing to fix glitches & get rid of hacks
  • Top-bar operator settings: Add simple "More..." button to show all settings
  • Fix headers not using correct background color
  • Clarify region size refreshing code in ED_screen_ensure_updated
  • Cleanup: Change flag name, add comment
  • Cleanup: Remove leftovers from when branch was based on workspace branch
  • Cleanup: Avoid duplicated topbar creation code in versioning code

@Brecht Van Lommel (brecht), all you're code review comments should be addressed now. UI polish we can still do once this is in blender2.8 (and after further discussion). If you experienced any issues with Retina, I think this should work now.
Also, I'll probably add an EditorStage or something like that as proposed. Won't do that before blender2.8 is merged back into master though, would cause too many conflicts.

source/blender/editors/interface/interface_layout.c
3505

Moved function into interface_templates.c, rBefd70ab78f0c.

Will leave the button text as is for now. Should be discussed with UI-team designers first.

Julian Eisel (Severin) marked an inline comment as done.Oct 23 2017, 3:16 AM
Julian Eisel (Severin) edited the summary of this revision. (Show Details)Oct 23 2017, 3:18 AM
Julian Eisel (Severin) edited the summary of this revision. (Show Details)Oct 23 2017, 3:21 AM
Sergey Sharybin (sergey) requested changes to this revision.Oct 23 2017, 5:56 PM

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.
  • Vertical alignment is broken.
  • With the factory startup, move the cube, tweak vector in the top bar and you will get convertViewVec: called in an invalid context.
  • All operator options in a single line doesn't read easily at all. There is also More button even when all properties are visible.
  • 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.

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

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. There are also some core design concepts which i'm not sure how will sustain in the future (like, the motion tracking layout).

This revision now requires changes to proceed.Oct 23 2017, 5:56 PM

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.

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.

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.

  • 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.

  • 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).

Julian Eisel (Severin) updated this revision to Diff 9479.EditedSat, Oct 28, 1:08 AM
  • Move info editor removal versioning code to pre-lib-linking stage
  • Remove operator redo panel from clip editor
  • Solve context issues when tweaking operator settings from top-bar
  • Fix crash when trying to make top-bar area full-screen
  • Forbid flipping regions in top-bar
  • Fix crash when trying to maximize area while hovering separator
  • Corrections to screen-vertex placement
  • Workaround for 1 px button alignment issue
  • Refactor operator settings drawing to support operator-macros
  • Fix top-bar showing "Redo Unsupported" in operator settings again

Patch is ready for another round of review now.

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.

  1. 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.

  1. 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.

  1. 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.

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.