Main Workspace Integration
Needs ReviewPublic

Authored by Julian Eisel (Severin) on Jan 6 2017, 12:01 AM.

Details

Summary

Main Workspace Integration

This patch does the main integration of workspaces, which is a concept we agreed on during the 2.8 UI workshop (check the write-up).
Patch/branch based on blender2.8.

Main Changes/Features

  • Introduces the new Workspaces (general description).
  • Store screen-layouts (bScreen) per workspace.
  • Store an active screen-layout per workspace. Changing the workspace will enable this layout.
  • Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
  • Moved mode switch from 3D View header to Info Editor header.
  • Store active scene in window (not directly workspace related, but overlaps quite a bit).
  • Removed 'Use Global Scene' User Preference option.
  • Compatibility with old files - a new workspace is created for every screen-layout of old files.
  • Default .blend only contains one workspace though ('General'). Idea is that users can add pre-configured workspaces from a menu, rather than having a bunch of default ones of which most will probably never be used.
  • Support appending workspaces.
  • Ctrl+Left and Ctrl+Right now cycle through workspaces instead of screens - not sure if that's what users want.

Also made sure opening files without UI and command-line rendering works fine.

Temporary UI for until new top-bar implementation is done.

Notes:

  • Workspaces are data-blocks.
  • Adding and removing bScreens should be done through ED_workspace_layout API now.
  • A workspace can only be visible in one window. If it could be displayed in multiple ones, all these workspaces would share the same UI data (same editors, same layout, same editor settings, etc) - which doesn't make much sense. Duplicating a window or opening an area in a new window duplicates the active workspace too.
  • The same applies to screen-layouts too. This is nothing new, current Blender already works like this.
  • The mode menu (which is now in the Info Editor header) doesn't display Grease Pencil Edit mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
  • Screen-layouts (bScreen) are IDs and thus stored in a main list-base. Had to add a wrapper WorkSpaceLayout so we can store them in a list-base within workspaces, too. I think on the long run we could completely replace bScreen by workspace structs (by moving screen-layout data to WorkSpaceLayout and everything else to WorkSpace).
  • WorkSpace types should only be accessed through BKE_workspace API, added a compile time check to ensure their DNA headers are only included in DNA and BKE_workspace namespace.
  • For a really few cases, we need the scene within a area/region listener. Previously we could get it from the screen, now we pass it as parameter to the listener. Not so nice to have this for such few cases.
  • Added scene operators SCENE_OT_, was previously done through screen operators.
  • Renamed directories editors/screen/ to editors/workspace/, renamed notifier NC_SCREEN to NC_WORKSPACE (screen is part of workspace now).

Additional changes I had to make:

  • Reworked how we store custom transform orientations in 3D Views. Previously it was enough to store the index of the active orientation in a 3D View as we were always able to find out which scene a 3D View belongs to. This isn't the case now that the scene is stored in the window, because inactive workspaces don't belong to a specified window. When removing a custom orientation we still need to unset it from each 3D view that uses it though, so we need to identify it reliably. Solved by additionally storing the active custom orientation in the 3D view as a pointer, so we can always identify it correctly when removing it.
  • Added support for template_ID to use a custom list to search the IDs in. Needed so workspaces display their own list of screens, not the main list.
  • Added support for data-blocks that are either linkable, appendable or both. Needed so workspaces can be appended but not linked (a linked workspace would mean its entire UI isn't editable).

BPY API Changes

  • Removed Screen.scene, added Window.scene
  • UILayout.template_ID and UILayout.template_ID_preview now additionally take search_data and search_property as parameters to define a custom collection to search the IDs in (optional).
  • Removed UserPreferencesView.use_global_scene
  • Added Context.workspace, Window.workspace and BlendData.workspaces
  • Added bpy.types.WorkSpace containing screen (active screen), screens and object_mode

What's left?

  • Make workspaces part of 'workflow' files -
    https://code.blender.org/wp-content/uploads/2016/12/Workspaces.jpg
  • There are a few open design questions (T50521). We should find the needed answers and implement them.
  • Get the new layer system ready and make workspaces store the active layer.
  • Get the override system ready and support overrides per workspace.
  • Support custom UI setups as part of workspaces.
  • Allow enabling add-ons per workspace.
  • Support custom workspace keymaps.
  • Allow adding a pre-defined workspace from a menu (asset manager?)
  • Workspaces need an icon :)

Diff Detail

Repository
rB Blender
Branch
workspaces
Build Status
Buildable 400
Build 400: arc lint + arc unit
Julian Eisel (Severin) updated the summary for this revision. (Show Details)Jan 6 2017, 12:13 AM
Julian Eisel (Severin) updated the summary for this revision. (Show Details)
Julian Eisel (Severin) updated the summary for this revision. (Show Details)
Julian Eisel (Severin) updated the summary for this revision. (Show Details)Jan 6 2017, 12:16 AM

As for the state of this: The branch appears to work rock solid now. I don't plan any more changes so feel free to test/review for merge into blender2.8 :)

Julian Eisel (Severin) updated the summary for this revision. (Show Details)Jan 6 2017, 12:42 AM

Eeek.... sorry for the noise :/

The patch is too big for a throughout review (>10k lines). Any part in particular you think needs cross-checking?

Also, I was under the impression that the user's detault workspaces would be saved in a separate file. I think the patch is not covering this.

Could you create a Doc on how to use this to help with testing. Ive built a branch and compiled for others to test but unclear how to utilize it, For example you image above which shows the workspace tabs at the top of the screen, How do i create these setups? Cheers J

  • Fix compile error and warning in release builds
  • Fix and compile time option for workspace object-mode
  • Merge branch 'blender2.8' into workspaces

Sorry guyzz for letting you wait that long! (tm) Real live dared to take all my attention.

The patch is too big for a throughout review (>10k lines). Any part in particular you think needs cross-checking?

I guess for your layer work the most interesting part would be the DNA/RNA stuff which is quite small actually.

Also, I was under the impression that the user's detault workspaces would be saved in a separate file. I think the patch is not covering this.

No, it isn't yet (as mentioned in the description ;). I think we need some more discussion on this to make sure all use cases are covered. Once that's done I'm happy to do the needed changes.


@Bastien Montagne (mont29), there are a couple of things on which I'd love to hear your input on:

  • General integration of the WorkSpace ID type (esp. lib-query and such).
  • Support for appendable-only data-blocks. That'd mainly be the changes from rB18ae49948fad5.
  • Changes done to template_ID to support custom RNA collection to take IDs from, see rB387bc547cb781445.
  • Any ideas on how to implement the predefined workspaces? Plan was to have a '+' tab in the topbar to create a new workspace, spawning a list of predefined workspaces the user can choose from. This way we don't waste space with workspace-tabs that'll never be used, without dropping the ready-to-use UI presets for different tasks. I guess we could store these workspaces in the workflow files, I'm just not sure how to query them for listing in the UI. Could Amber handle this part? Or maybe the preset system could support this?
  • Any thoughts on per workspace add-ons? I guess this would mean having a bAddon list saved in workspaces which would be registered/unregistered when changing workspaces. Think that's doable but I could imagine there would be performance hiccups and such. There's also the case of opening a workspace with an add-on not available. Maybe per workspaces add-ons should be stored as overrides of the UserPref ones internally, so we can handle such cases nicely.

@Bastien Montagne (mont29) & @Dalai Felinto (dfelinto), you both may want to look into the main workspace APIs (/blenkernel/intern/workspace.c, /blenkernel/BKE_workspace.h and /editors/workspace/workspace_edit.c) and into the Python API changes. The patch description should list all changes for the latter one.


Could you create a Doc on how to use this to help with testing. Ive built a branch and compiled for others to test but unclear how to utilize it, For example you image above which shows the workspace tabs at the top of the screen, How do i create these setups? Cheers J

To be honest I don't think this should get some user testing just now. Not because I don't think it's stable (well in fact there are some known issues with the temporary implementation of workspace-level object-mode), but because I don't think it's really usable at all just now. This patch is part of a number of bigger changes that create a big picture change all together, but on it's own it isn't worth much for users.

Julian Eisel (Severin) updated the summary for this revision. (Show Details)Jan 24 2017, 9:05 PM

There's T50521 now for further design discussion. The points regarding workspace sharing and multi-window setups might influence how we'll be saving data to files. So if we want to avoid breaking files created with blender2.8, we should probably hold off with the merge until questions are answered and needed changes done.