Custom editor modes proposal #97234

New Issue

Campbell Barton · 2022-04-11T05:40:51+02:00

Campbell Barton commented

2022-04-11 05:40:51 +02:00

Motivation

Currently a mode and it's internal data structures are closely related,
which has been fine for most general use cases however can limit extending Blender for more specific work-flows.

There are two projects which prompted investigation into this task.

Retopology project (uses edit-mesh for retopology tools).
Color painting addition to sculpt mode further clutters the layout.

Both these projects are an example where a new mode makes sense from the user perspective,
but the internal data being stored can be shared between multiple "modes".

This proposal suggests a way we can support modes such as "Vertex Paint" or "Retopology" mode,
while internally sculpt or edit-mode data may be used.

The advantage of this is we avoid having a lot of hard coded checks in the code,
as well as the potential for add-ons to define their own modes & work-flows.

Proposed Solution

Add support for C/C++ & Python code to register custom modes, allowing add-ons and app-templates to make use of this.

Expose these modes in the UI (mode-selector and possibly pie-menu TBD.

Validate the design with proto-type modes, gather feedback from developers and script authors.

Components

Here are the main components that a custom-mode is comprised of.

Customizable: the following elements should be (optionally) customizable:
- Key-map.
- Menus (header layout).
- Tools.

Custom-Modes may also use existing facilities:

Operators.
Gizmos.
Panels.
Region Drawing Callbacks.
Static: There is currently no intention to make these areas customizable.
- Drawing (entirely replacing view-port drawing for example).
  
  Although it may be useful to have drawing options to fit the needs of modes such as retopology.
- Animation/Depsgraph/Notifications.
- Undo system.

NOTE: this doesn't prevent additional customization from being supported later on.

Scope

The main use case for customizing modes will be custom object modes.
however there is no reason the design needs to enforce this limitation.

This can be written in a way that a custom-mode can be reference a space-type as well,
so in the future it's possible to have custom image/UV/sequencer ... or other modes.

Customizing Components

Modes can be registered similar to rendering engines, operators etc.

import bpy
from bpy.types import CustomMode

# Load an icon.
icon_id = ...

class MyMode(CustomMode):
   bl_idname = 'MY_MODE_ID'

   bl_space_type = 'VIEW_3D'
   bl_mode_parent = 'EDIT_MESH'
   bl_icon_id = icon_id

   def poll(self, context):
       # Return false if this mode shouldn't be listed.
       return True

   # Run when entering the mode.
   def enter(self, context):
      pass

   # Run when exiting the mode.
   def exit(self, context):
      pass

   # Draw menus (keep the view menu and space selector as-is).
   def draw_header_menus(self, context):
      ...

   def setup_tools(self, context):
      ...
      return tools

   def setup_keymap(self, context):
      ...
      return keymap


bpy.types.register_class(MyMode)

This is just a rough outliner of how this could work.

Internal Details

To avoid increasing complexity the Object.mode and Context.mode will be left as is.
An additional custom/derived mode will be available for code that needs to check the mode to draw the UI handle key-maps
etc.

Challenges / Pain Points

Layering Key-maps

Mixing app-templates keymaps with Blender's existing key-map is likely to be a pain-point.
I don't think there is any magic bullet here,
We could mitigate the problem by having API's to more conveniently check which keys are available for e.g.
but I think for the most-part app-templates will need to be created, knowing which key-map they will run on-top of.

Keymap Editing

Some time should be spend to ensure the key-maps of the custom-modes can be properly customized by the key-map editor.

UI/UX & Arbitrary Number of Modes

By default modes won't have key-shortcuts and they may not fit into the pie menu.

There are various options for how to extend the pie menu with pros/cons,
I'd rather discuss this separately from this proposal as I'd rather involve others in the UI project.

To begin with we could limit these modes to the drop-down menu.

Open Topics

These topics are our of scope for this proposal or can be postponed.

Naming

This could be called `EditorMode`, `DerivedMode`, `CustomMode` ...
`EditorMode` seems most correct as the mode is bound to an editor.

Granularity of Overrides

Users may want to manipulate the current UI instead of replace parts of it.
To begin with I'd like to keep the design managable by either setting a keymap/tools... etc or not.
In the future we could investigate ways to give more control over the granularity of overrides.

Note that Blender already provides ways to extend the UI, it's possible to add tools & menu items for e.g.
so script authors who wish only to make minor changes to the UI could make use of this.
Although I don't think it's good to rely on this as the primary way custom-modes would customize the UI
as those methods mostly add items where custom-modes are likely to want to replace key-maps.

Customizing Headers

Header drawing could be handled a few different ways,
in many cases we will only want to replace the some of the menus
(keep the "View" menu and 3D viewport shading buttons for example).

Side-Bar

I don't see the need to replace panels in the Side-Bar,
we could probably use the existing method registering panels that poll for custom-modes.

Motivation **** Currently a mode and it's internal data structures are closely related, which has been fine for most general use cases however can limit extending Blender for more specific work-flows. There are two projects which prompted investigation into this task. - Retopology project (uses edit-mesh for retopology tools). - Color painting addition to sculpt mode further clutters the layout. Both these projects are an example where a new mode makes sense from the user perspective, but the internal data being stored can be shared between multiple "modes". This proposal suggests a way we can support modes such as "Vertex Paint" or "Retopology" mode, while internally sculpt or edit-mode data may be used. The advantage of this is we avoid having a lot of hard coded checks in the code, as well as the potential for add-ons to define their own modes & work-flows. Proposed Solution **** Add support for C/C++ & Python code to register custom modes, allowing add-ons and app-templates to make use of this. Expose these modes in the UI (mode-selector and possibly pie-menu *TBD*. Validate the design with proto-type modes, gather feedback from developers and script authors. Components **** Here are the main components that a custom-mode is comprised of. * **Customizable:** the following elements should be (optionally) customizable: * Key-map. * Menus (header layout). * Tools. ``` Custom-Modes may also use existing facilities: ``` * Operators. * Gizmos. * Panels. * Region Drawing Callbacks. * **Static:** There is currently no intention to make these areas customizable. * Drawing (entirely replacing view-port drawing for example). *Although it may be useful to have drawing options to fit the needs of modes such as retopology.* * Animation/Depsgraph/Notifications. * Undo system. NOTE: this doesn't prevent additional customization from being supported later on. Scope ----- The main use case for customizing modes will be custom object modes. however there is no reason the design needs to enforce this limitation. This can be written in a way that a custom-mode can be reference a space-type as well, so in the future it's possible to have custom image/UV/sequencer ... or other modes. Customizing Components ---------------------- Modes can be registered similar to rendering engines, operators etc. ``` import bpy from bpy.types import CustomMode # Load an icon. icon_id = ... class MyMode(CustomMode): bl_idname = 'MY_MODE_ID' bl_space_type = 'VIEW_3D' bl_mode_parent = 'EDIT_MESH' bl_icon_id = icon_id def poll(self, context): # Return false if this mode shouldn't be listed. return True # Run when entering the mode. def enter(self, context): pass # Run when exiting the mode. def exit(self, context): pass # Draw menus (keep the view menu and space selector as-is). def draw_header_menus(self, context): ... def setup_tools(self, context): ... return tools def setup_keymap(self, context): ... return keymap bpy.types.register_class(MyMode) ``` This is just a rough outliner of how this could work. Internal Details ---------------- To avoid increasing complexity the `Object.mode` and `Context.mode` will be left as is. An additional custom/derived mode will be available for code that needs to check the mode to draw the UI handle key-maps etc. Challenges / Pain Points **** * **Layering Key-maps** ``` Mixing app-templates keymaps with Blender's existing key-map is likely to be a pain-point. I don't think there is any magic bullet here, We could mitigate the problem by having API's to more conveniently check which keys are available for e.g. but I think for the most-part app-templates will need to be created, knowing which key-map they will run on-top of. ``` * **Keymap Editing** ``` Some time should be spend to ensure the key-maps of the custom-modes can be properly customized by the key-map editor. ``` * UI/UX & Arbitrary Number of Modes ``` By default modes won't have key-shortcuts and they may not fit into the pie menu. ``` ``` There are various options for how to extend the pie menu with pros/cons, I'd rather discuss this separately from this proposal as I'd rather involve others in the UI project. ``` ``` To begin with we could limit these modes to the drop-down menu. ``` Open Topics **** These topics are our of scope for this proposal or can be postponed. * **Naming** ``` This could be called `EditorMode`, `DerivedMode`, `CustomMode` ... `EditorMode` seems most correct as the mode is bound to an editor. ``` * **Granularity of Overrides** ``` Users may want to manipulate the current UI instead of replace parts of it. To begin with I'd like to keep the design managable by either setting a keymap/tools... etc or not. In the future we could investigate ways to give more control over the granularity of overrides. ``` ``` Note that Blender already provides ways to extend the UI, it's possible to add tools & menu items for e.g. so script authors who wish only to make minor changes to the UI could make use of this. Although I don't think it's good to rely on this as the primary way custom-modes would customize the UI as those methods mostly add items where custom-modes are likely to want to replace key-maps. ``` * **Customizing Headers** ``` Header drawing could be handled a few different ways, in many cases we will only want to replace the some of the menus (keep the "View" menu and 3D viewport shading buttons for example). ``` * **Side-Bar** ``` I don't see the need to replace panels in the Side-Bar, we could probably use the existing method registering panels that poll for custom-modes.

Campbell Barton commented

2022-04-11 05:40:51 +02:00

Added subscriber: @ideasman42

Campbell Barton changed title from ~~Custom modes ()~~ to Custom editor modes proposal

2022-04-11 05:41:17 +02:00

Campbell Barton self-assigned this 2022-04-11 05:41:17 +02:00

Campbell Barton commented

2022-04-11 05:41:17 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

TheRedWaxPolice commented

2022-04-11 09:14:06 +02:00

Added subscriber: @TheRedWaxPolice

Ramil Roosileht commented

2022-04-11 13:30:53 +02:00

Added subscriber: @Limarest

Ramil Roosileht commented

2022-04-11 13:30:53 +02:00

Sound useful. It would also let the users customize existing modes. For example, making a custom sculpt mode where only a few brushes are present

Gio ¬_¬ commented

2022-04-11 19:12:32 +02:00

Added subscriber: @ga0338751

Paul Larson commented

2022-04-11 19:54:09 +02:00

Added subscriber: @GeorgiaPacific

Francesco Siddi commented

2022-04-11 19:54:48 +02:00

Added subscriber: @fsiddi

Campbell Barton commented

2022-04-12 05:29:57 +02:00

@Limarest yes, you could create a custom-mode that only replaces one of the customizable components (so yes, you could only replace the toolbar .... or keymap/menus ... etc).

Yuki Hashimoto commented

2022-04-15 12:52:30 +02:00

Added subscriber: @hzuika

RedMser commented

2022-04-15 12:56:20 +02:00

Added subscriber: @RedMser

Kévin Dietrich commented

2022-06-04 17:34:18 +02:00

Added subscriber: @kevindietrich

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Custom editor modes proposal #97234

Scope

Customizing Components

Internal Details