When switching the workspace in a window that does not yet have a layout
for the newly active workspace, we now duplicate the layout from the
previously active workspace. Previously it duplicated the layout from
the first window in the newly active workspace.
It was a bit odd that the scene was stored per window but not the view
layer. The reasoning was that you would use different view layers for
different tasks. This is still possible, but it's more predictable to
switch them both explicitly, and with child window support manually
syncing the view layers between multiple windows is no longer needed
as often.
* Main windows show a topbar and statusbar, and select a workspace and
scene. They are created with Window > New Main Window.
* Child windows do not show a topbar or statusbar. These follow the
workspace and scene of their parent main window. Created with Window >
New Window or View > Duplicate Area into New Window.
* The purpose of this change is to support multi monitor setups where you
just want to put more editors on the other monitors. Without multiple
topbars and statusbars, working within a single workspace and scene.
Creating multiple main windows is intended to be a concious choice to
do different tasks in different workspaces and scenes.
* Note these changes do not currently affect how the operating system
treats the windows.
* When changing the workspace, the layout in all child windows changes.
This makes sense if we consider child windows to be just a way to
extend the main window across more monitors. In some case it may be
useful to keep the same layout though, we can add an option for this
depending on user feedback.
Make room for Alt-A to be used for de-select.
Discussed with artists in studio & @venomgfx,
- Use Ctrl-Space for animation.
- Use Ctrl-Tab to toggle manipulator.
- Remove mirror transform binding.
Operators ignored edges along the screen-layout bounds. They should've ignored
those along window bounds instead.
Although the global areas can not be joined/split, the adjacent areas can. So
the menu should still be shown.
Had to change the return value of area joining operator, so that an error report
can show up when trying to join over a global area edge. Think this is fine to
do, but you never know with such stuff.
Preferably we'd gray out the "Join Area" item in the menu when clicking on the
edge of a global area. Unfotunately the operator uses coordinates passed as
operator properties to find the right edge/areas, which we cannot access from
the poll callback.
Just like the top-bar, the status-bar can now be hidden/collapsed by dragging
its edge. We display a small line with the editor outline color then, so there
is something that can be dragged up to un-collapse the area again.
This collapsed state is not written to files yet.
For example collapsing the lower part of the topbar with 2x interface scale
would hide the top-bar header region. There were also more asserts when changing
window size and moving area edges afterwards (same assert as in T55298).
Fixes are similar to e626998a26.
With all the recent fixes I've done, area geometry handling should be stable
again. Let's hope I'm right :)
This used to be rather cryptic and it was easy to forget the `+ 1` which in fact
is needed to get the correct width/height, see e626998a26. This should
also fix some minor off-by-one errors.
Caused by ca8f787349. This issue is in master actually. Fixing it there
would cause conflicts so won't do that unless needed ;)
Steps to recreate were:
* Split properties editor into two (default startup.blend)
* Move both properties editors to the bottom, so only their headers are visible
* Move the upper edge of the upper properties editor up and down
Although it doesn't happen everytime, you may see the edge between the timeline
and the 3D view move, while the region drawing doesn't update.
What happened is area edge snapping allowed to snap the edge outside of window
bounds (we snap to a 4px grid by default), which screen_vertices_scale
interpreted as window scaling and thus run area size updates.
Referring to ca8f787349. Thought in this case the simple `+ 1` would be
correct, but we need to make the same pixel adjustment as we do in other places.
Simply moving the properties editor of the default startup.blend all the way to
the bottom could trigger this. Calculating limits for area edge moving would use
screen bounds instead of entire window bounds (screen + global bars).
Added assert that should help debugging further issues like this.
