Arrrg, no! Pasted wrong commit hash... This was in fact caused by rB7ffe838473a7f0b4a, not ca8f787349dcdf5.

I think the best way to go about this is what we agreed on during the 2.8 UI workshop:

Info Editor

Since we plan to introduce the global top bar, we can also repurpose the Info Editor. It would be the expanded, much more detailed version of the status bar. Our place for all kinds of statistics and logs.

The Info Editor could contain:

• Notification logs (log of last displayed warnings, errors and hints)
• Information about currently open .blend file
• Log of executed operators
• Detailed information about on-going jobs
• Diverse statistics (memory, polygon count, object count, ...)
• Hardware/Driver information (maybe system-info.txt can be integrated a bit nicer here?)

See https://en.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Info_Editor.

The way things work right now is totally intentional. Only code that actually deals with area geometry (ScrEdges and ScrVerts) should use ScrArea.vn. The bounds of ScrArea.totrct and the ScrArea.vn vertices are not supposed to match. Doing so would reduce the space between editors:

Current	With patch

I'm a bit skeptical about using the number keys for mode changing too. When changing a mode, users also typically change the task they are doing (object mode is an exception). That is exactly what workspaces should handle though - each workspace would have it's own mode set, e.g. the "Animation" workspace would be in pose mode, the "Retopo" workspace would be in edit mode with necessary tools, add-ons and viewport settings loaded. See T55246 & T53389.
So in the big picture, the workspace mode and multi-object editing would mean users switch modes far less frequent. Instead they would change workspaces. They'd probably still regularly toggle between Object Mode and the workspace mode.

Improvements to BLI_str_format_bytes:

• Rename to BLI_str_format_byte_unit
• Use long long int as argument, not double. Floating point byte-count doesn't make much sense, it's only needed for internal purposes.
• Strip trailing zeroes.
• Support passing negative values - not sure if that's useful even, but simple to support.
• Improve test coverage, esp. for corner-cases.
• General cleanup (codestyle, naming, comments, etc.)

Stumbled over this today and made some changes (updating patch in a minute). Should be ready to go now.

This is most likely a graphics driver failure, you can try if updating your driver fixes the issue.

It should definitely be possible to hide it by dragging its edge - just like the lower part of the top-bar.

Not sure if there are currently specific rules for triaging Code Quest reports, but guess it's reasonable to tag this as high priority.

Same happens in Text Editor and Console (note, you have to draw over main region, not over the header). This is caused by rB6e40b2de7ae81653f.
Another way to reproduce this is by using --debug-memory and joining any areas.

This fixes the issue:

For the records, this is pretty high on my priority list. I'm planning to look into it asap. Unfortunatly that may only be after the weekend though.

Why would we move those settings into the top-bar? It's nice to have all tool-settings in a single place, however some of the mentioned settings are merely 3D View settings. And the ones that are shared across multiple editor types usually vary depending on the editor type. E.g.:

I actually agree on what @Linus Wiklander (wiklander) said, I'd also prefer keeping the Render Size Percentage at 50% to force people into discovering it ;)

Hmm, I'd say screen-verts must never have a negative coordinate, if so there's probably a bug. So the assert seems to be right. Would still have to check details though.

Thanks a lot! I did work on a patch taking the same direction as yours, just didn't get around to finish it. Glad it's fixed now!

Huuuuge thumbs up for the general proposal! I've been very worried about the complexity of the new layer/collection system; this addresses my concerns just fine and is in fact quite similar to what I had in mind.
No more linking, instead you define you're hierarchy once and define a sub-set of it for each layer -- so much yes!

Also, RegionEmbossSide is unused now and should be removed.

This is removing region emboss, but in the commit message you speak about area emboss. So either you removed the wrong emboss or used the wrong term :) What was your intention?

Hey and happy lekker Sunday! ;)

I think this depends a bit on how we want to handle scrolling in the top-bar. If we don't want any scrolling and instead do things like moving tabs into a '...' menu if there are to many to display, the second solution sounds better. If we want to make sections scrollable option one should be the way to go.