Change Details

About This Proposal =================== This document is mostly concerned with the and functionality and internal design, some UI aspects are not set-in-stone and wont be covered in detail here. This proposal mixes functionality with implementation details (normally I try to avoid this), however in this case I would like to get feedback from other developers on how this is integrated. Motivation ========== While using keyboard shortcuts is efficient, this isn't easily accessible for users who don't memorize the, and while some tools can be accessed from the tool-bar, this doesn't work well for tools that depend on pointer position, eg: - Drawing tools (grease pencil, 3D curve drawing...). When drawing is not a //Mode//, accessing each time from the toolbar isn't convenient. - Transform Tools When accessing from a pointer with absolute positioning especially. Note that the current keyboard-oriented workflow will still be a first-class citizen, A tool system will be added without disturbing the workflow of users who prefer key shortcuts which are more efficient. Example Use Cases ================= - Extrude Tool Activating the tool could show a widget with handles to extrude the region or individual faces. - Drawing Tool Activating means each stroke can be performed without accessing the tool each time. Note that grease pencil is becoming it's own mode, it may be able to use the tool system too. (remove the need for "Continuous Drawing" option). - Circle Select Tools Allows for circle select to exit after each stroke - so the user can adjust the view (common request). - Primitive Creation Tool (maybe?) This would allow clicking and dragging to create primitive shapes (box, sphere, plane... etc). ... adding other examples would be good. Implementation ============== Accessing Tools --------------- Tools will most likely be accessed from the toolbar, we will likely have the button remain pressed while it's active. Some tools may use key bindings to activate them too //(we can sort out these details later though)//. Active Tool ----------- - Each work-space will have an active tool. //This will simply be the name of an operator.// - The current interactions (3D cursor placement, accessing the manipulator) will be exposed as a tool, so from the users perspective there will always be an active tool. - The options for the active tool will be displayed in the top-bar. - Each works-space will only have a single active tool. //We may want to investigate per space-type tools later, see details below.// - Setting the active tool wont execute or run a modal handler, instead, a key-map will be activated that takes priority over the area's keymap. This will likely be assigned to the operator-type, as we have already for modal key-maps. //Note that I expect we will have a generic tool key-map that can be used for most tools, only some will require custom key-maps.// - Internally, activating a tool will use an operator `bpy.ops.wm.tool_activate("curve.draw", properties={...})` for example. Tool Settings ------------- In general we will make use of existing operator properties functionality. Currently operator types store their last-used properties, this can be used for top-bar properties too. This is needed since the operator may not be running while the properties are being edited. As with key bindings for operators, the key-map to activate a tool may include operator properties to be used. Later on we may want to store tool-settings separately from last-used options, we might want save these into the file too. Manipulators ------------ Active tools may have associated manipulators, these can be loosely coupled - as we have already with operators. In some cases it makes sense to have the manipulators only available once the tools are running (spin, bisect tools for example). In these cases the operator is responsible for manipulators //(this is already working in the 2.8 branch)//. In other cases we will want a tool to have associates manipulators which is immediately available. (extrude tool for example). This can be supported by adding a "manipulator_type" field to the operator-type, on activating an operator-type as a tool, it's manipulator-type will be registered for the current space-type. On de-activating the manipulator types will be unregistered with the space types. Note, this matches how operators already add/remove manipulators when they're used with operators. This avoids having all manipulators for all possible tools active at once, with their poll functions continuously checking the active tool. For C code this may not be much overhead, we will have Python manipulators too. Known Unknowns ============== - Editing operator properties of an operator that isn't running means the operator's "check" callback wont run. This is currently used by some operators to sanitize properties when edited in the toolbar (disallowing impossible combinations of options). This is similar to editing properties in the key-map editor (where no sanity checks are done). So we can just accept properties may be sanitized on first use. Another option could be to support running the "check" callback without an operator instance //(wary of this since we will be using one callback in quite different ways).// - We may want to have per space-type active tool, this may be complicated unless we have an active area too. Some applications do this by having the first click activate the area, similar to clicking on a window to focus. I don't think this would fit well in Blender though. Some possible solutions: - It may work to store a per space-type tool in the works-space, showing the last used tool-options in the top-bar, this avoids having to re-select the tool when entering a space. However it means you wouldn't be able to access options from top-bar before using the tool in a different space. - Another possible solution could be to have a way to change space-types from the top bar //(This feels like a weak workaround, just including for completeness)// - Should multiple tools be accessible from a single button //(convention in some drawing applications is to click and old to select between variations of the same tool)//. - Should we show tool options in the-top bar which are not operator options? We may for example - want to have proportional falloff radius accessible from the top-bar. This is a tool setting, nevertheless users may expect to see this in the top-bar if its used for transform tools. //(More of a top-bar design issue really)//

About This Proposal =================== This document is mostly concerned with the end functionality and internal design, some UI aspects are not set-in-stone and won't be covered in detail here. This proposal mixes functionality with implementation details (normally I try to avoid this), however in this case I would like to get feedback from other developers on how this is integrated. Motivation ========== While using keyboard shortcuts is efficient, this isn't easily accessible for users who don't memorize them, and while some tools can be accessed from the tool-bar, this doesn't work well for tools that depend on pointer position, eg: - Drawing tools (grease pencil, 3D curve drawing...). When drawing is not a //Mode//, accessing each time from the toolbar isn't convenient. - Transform Tools When accessing from a pointer with absolute positioning especially. Note that the current keyboard-oriented workflow will still be a first-class citizen, A tool system will be added without disturbing the workflow of users who prefer key shortcuts which are more efficient. Example Use Cases ================= - Extrude Tool Activating the tool could show a widget with handles to extrude the region or individual faces. - Drawing Tool Activating means each stroke can be performed without accessing the tool each time. Note that grease pencil is becoming it's own mode, it may be able to use the tool system too. (remove the need for "Continuous Drawing" option). - Circle Select Tools Allows for circle select to exit after each stroke - so the user can adjust the view (common request). - Primitive Creation Tool (maybe?) This would allow clicking and dragging to create primitive shapes (box, sphere, plane... etc). ... adding other examples would be good. Implementation ============== Accessing Tools --------------- Tools will most likely be accessed from the toolbar, we will likely have the button remain pressed while it's active. Some tools may use key bindings to activate them too //(we can sort out these details later though)//. Active Tool ----------- - Each work-space will have an active tool. //This will simply be the name of an operator.// - The current interactions (3D cursor placement, accessing the manipulator) will be exposed as a tool, so from the users perspective there will always be an active tool. - The options for the active tool will be displayed in the top-bar. - Each work-space will only have a single active tool. //We may want to investigate per space-type tools later, see details below.// - Setting the active tool won't execute or run a modal handler, instead, a key-map will be activated that takes priority over the area's keymap. This will likely be assigned to the operator-type, as we have already for modal key-maps. //Note that I expect we will have a generic tool key-map that can be used for most tools, only some will require custom key-maps.// - Internally, activating a tool will use an operator `bpy.ops.wm.tool_activate("curve.draw", properties={...})` for example. Tool Settings ------------- In general we will make use of existing operator properties functionality. Currently operator types store their last-used properties, this can be used for top-bar properties too. This is needed since the operator may not be running while the properties are being edited. As with key bindings for operators, the key-map to activate a tool may include operator properties to be used. Later on we may want to store tool-settings separately from last-used options, we might want save these into the file too. Manipulators ------------ Active tools may have associated manipulators, these can be loosely coupled - as we have already with operators. In some cases it makes sense to have the manipulators only available once the tools are running (spin, bisect tools for example). In these cases the operator is responsible for manipulators //(this is already working in the 2.8 branch)//. In other cases we will want a tool to have associates manipulators which is immediately available. (extrude tool for example). This can be supported by adding a "manipulator_type" field to the operator-type, on activating an operator-type as a tool, it's manipulator-type will be registered for the current space-type. On de-activating the manipulator types will be unregistered with the space types. Note, this matches how operators already add/remove manipulators when they're used with operators. This avoids having all manipulators for all possible tools active at once, with their poll functions continuously checking the active tool. For C code this may not be much overhead, we will have Python manipulators too. Known Unknowns ============== - Editing operator properties of an operator that isn't running means the operator's "check" callback wont run. This is currently used by some operators to sanitize properties when edited in the toolbar (disallowing impossible combinations of options). This is similar to editing properties in the key-map editor (where no sanity checks are done). So we can just accept properties may be sanitized on first use. Another option could be to support running the "check" callback without an operator instance //(wary of this since we will be using one callback in quite different ways).// - We may want to have per space-type active tool, this may be complicated unless we have an active area too. Some applications do this by having the first click activate the area, similar to clicking on a window to focus. I don't think this would fit well in Blender though. Some possible solutions: - It may work to store a per space-type tool in the works-space, showing the last used tool-options in the top-bar, this avoids having to re-select the tool when entering a space. However it means you wouldn't be able to access options from top-bar before using the tool in a different space. - Another possible solution could be to have a way to change space-types from the top bar //(This feels like a weak workaround, just including for completeness)// - Should multiple tools be accessible from a single button //(convention in some drawing applications is to click and old to select between variations of the same tool)//. - Should we show tool options in the-top bar which are not operator options? We may for example - want to have proportional falloff radius accessible from the top-bar. This is a tool setting, nevertheless users may expect to see this in the top-bar if its used for transform tools. //(More of a top-bar design issue really)//

About This Proposal =================== This document is mostly concerned with the andend functionality and internal design, some UI aspects are not set-in-stone and won't be covered in detail here. This proposal mixes functionality with implementation details (normally I try to avoid this), however in this case I would like to get feedback from other developers on how this is integrated. Motivation ========== While using keyboard shortcuts is efficient, this isn't easily accessible for users who don't memorize them, and while some tools can be accessed from the tool-bar, this doesn't work well for tools that depend on pointer position, eg: - Drawing tools (grease pencil, 3D curve drawing...). When drawing is not a //Mode//, accessing each time from the toolbar isn't convenient. - Transform Tools When accessing from a pointer with absolute positioning especially. Note that the current keyboard-oriented workflow will still be a first-class citizen, A tool system will be added without disturbing the workflow of users who prefer key shortcuts which are more efficient. Example Use Cases ================= - Extrude Tool Activating the tool could show a widget with handles to extrude the region or individual faces. - Drawing Tool Activating means each stroke can be performed without accessing the tool each time. Note that grease pencil is becoming it's own mode, it may be able to use the tool system too. (remove the need for "Continuous Drawing" option). - Circle Select Tools Allows for circle select to exit after each stroke - so the user can adjust the view (common request). - Primitive Creation Tool (maybe?) This would allow clicking and dragging to create primitive shapes (box, sphere, plane... etc). ... adding other examples would be good. Implementation ============== Accessing Tools --------------- Tools will most likely be accessed from the toolbar, we will likely have the button remain pressed while it's active. Some tools may use key bindings to activate them too //(we can sort out these details later though)//. Active Tool ----------- - Each work-space will have an active tool. //This will simply be the name of an operator.// - The current interactions (3D cursor placement, accessing the manipulator) will be exposed as a tool, so from the users perspective there will always be an active tool. - The options for the active tool will be displayed in the top-bar. - Each works-space will only have a single active tool. //We may want to investigate per space-type tools later, see details below.// - Setting the active tool won't execute or run a modal handler, instead, a key-map will be activated that takes priority over the area's keymap. This will likely be assigned to the operator-type, as we have already for modal key-maps. //Note that I expect we will have a generic tool key-map that can be used for most tools, only some will require custom key-maps.// - Internally, activating a tool will use an operator `bpy.ops.wm.tool_activate("curve.draw", properties={...})` for example. Tool Settings ------------- In general we will make use of existing operator properties functionality. Currently operator types store their last-used properties, this can be used for top-bar properties too. This is needed since the operator may not be running while the properties are being edited. As with key bindings for operators, the key-map to activate a tool may include operator properties to be used. Later on we may want to store tool-settings separately from last-used options, we might want save these into the file too. Manipulators ------------ Active tools may have associated manipulators, these can be loosely coupled - as we have already with operators. In some cases it makes sense to have the manipulators only available once the tools are running (spin, bisect tools for example). In these cases the operator is responsible for manipulators //(this is already working in the 2.8 branch)//. In other cases we will want a tool to have associates manipulators which is immediately available. (extrude tool for example). This can be supported by adding a "manipulator_type" field to the operator-type, on activating an operator-type as a tool, it's manipulator-type will be registered for the current space-type. On de-activating the manipulator types will be unregistered with the space types. Note, this matches how operators already add/remove manipulators when they're used with operators. This avoids having all manipulators for all possible tools active at once, with their poll functions continuously checking the active tool. For C code this may not be much overhead, we will have Python manipulators too. Known Unknowns ============== - Editing operator properties of an operator that isn't running means the operator's "check" callback wont run. This is currently used by some operators to sanitize properties when edited in the toolbar (disallowing impossible combinations of options). This is similar to editing properties in the key-map editor (where no sanity checks are done). So we can just accept properties may be sanitized on first use. Another option could be to support running the "check" callback without an operator instance //(wary of this since we will be using one callback in quite different ways).// - We may want to have per space-type active tool, this may be complicated unless we have an active area too. Some applications do this by having the first click activate the area, similar to clicking on a window to focus. I don't think this would fit well in Blender though. Some possible solutions: - It may work to store a per space-type tool in the works-space, showing the last used tool-options in the top-bar, this avoids having to re-select the tool when entering a space. However it means you wouldn't be able to access options from top-bar before using the tool in a different space. - Another possible solution could be to have a way to change space-types from the top bar //(This feels like a weak workaround, just including for completeness)// - Should multiple tools be accessible from a single button //(convention in some drawing applications is to click and old to select between variations of the same tool)//. - Should we show tool options in the-top bar which are not operator options? We may for example - want to have proportional falloff radius accessible from the top-bar. This is a tool setting, nevertheless users may expect to see this in the top-bar if its used for transform tools. //(More of a top-bar design issue really)//