Change Details

This task is a collection of notes for several small to medium problems and possible solutions regarding painting assistants and the painting assistant tool. The idea is the consolidate all the necessary changes into a refreshed assistant tool. I feel like this is better than peppering small tweaks every minor release, and it would be a good look to have for the release of v5 :) Also perhaps it could lay the groundwork for more ambitious projects and improvements on painting assistants as a whole (eg T11345, T6543, Assistant Layers, Python API?, Animation?, etc) The motivation for this is to make Krita's assistants more useful, particularly in the perspective drawing department. My hope is for a refresh to achieve the following: - Encourage users who didn't use assistants to start using them - Encourage current users of assistants to use assistants more often than they already do - Help frequent users get more work done with assistants than they already do These notes are based on the current stable release of Krita, v4.3 = The Good = Functionally, most of the assistants are perfectly usable already. These assistants probably won't receive any user-visible changes - Ruler assistants and Spline assistants - Elliptical assistants - Vanishing Point assistant = The Bad = - There ought to be some way to limit the area of effect for assistants, this will be very helpful for comic authors - https://www.davidrevoy.com/article159/design-ideas-for-a-new-krita-perspective-tool - This will mean there will be LOTS of assistants on the canvas. This needs to be easy to manage - [tiar 28.05.21] this is done here: https://invent.kde.org/graphics/krita/-/merge_requests/850 - Users want more assistants for various linear perspective drawing workflows - 2PP Assistant https://bugs.kde.org/show_bug.cgi?id=405644 - 1PP Assistant https://krita-artists.org/t/proposal-for-a-1-point-perspective-assistant-tool/8377 - Yet another 2PP Assistant https://krita-artists.org/t/a-2-point-perspective-assistant-tool/8227 - I want a 3PP assistant - [tiar 28.05.21] one of the 2pp assistants has been implemented already (2vp + 1 vertical ruler which can be turned off). 3pp assistant can be *incredibly easily* made upon the 2pp assistant (the "centre of vision" replaced by 3rd vp). 1pp assistant is also needed (1vp + 2rulers), but it will need some smart drawing of the horizontal lines. - with the new 2pp assistant, 3pp can be easily done with 2pp assistant + vertical ruler turned off + one vanishing point. 1pp perspective can be done as usual: vanishing point + rulers. - Assistant control panels hiding each other and other assistants' handles https://bugs.kde.org/show_bug.cgi?id=396979 - [tiar] should be possible to do with the "editor position" in a variable instead of calculated; but it needs some smart thinking on the UI side (dragging the control panels by some recognizable icon) - No useful right-click menu unique to assistant tool - No Shift-snapping during assistant creation https://bugs.kde.org/show_bug.cgi?id=406204 - No mechanism to make assistants aware of each other / stitched together / aligned to each other / etc - Will be necessary for to align 2PP and 3PP assistants together - Necessary to align Perspective assistant with VP assistant - Assistant preview doesn't follow where the painting is happening on the canvas - [tiar] I think this has been fixed... - Can't select multiple assistants and operate on several at once = The Ugly = - Perspective Assistant: - Slashes the canvas FPS if you zoom in too close https://bugs.kde.org/show_bug.cgi?id=411352 - It has "side handles" that just make more Perspective assistants not aligned to anything in particular https://bugs.kde.org/show_bug.cgi?id=331787 - Doesn't integrate with the Vanishing Point assistant https://bugs.kde.org/show_bug.cgi?id=292684 - It's logic is weirdly tangled up in the assistant tool and the painting assistant class - Doesn't do any of the cool stuff that Transform tool can do eg rotating and resizing = Proposed Changes = == Popup Palette / RMB menu == TODO == Alternate actions== Assuming the configured alternate action key is Shift, we want specific helpful and documented things to happen when the user does the following when the assistant tool is active: - Shift-LMB-click: TODO - Shift-LMB-drag: TODO - Shift-LMB-move: TODO https://invent.kde.org/graphics/krita/-/merge_requests/414 == Tool Options changes == TODO == On-canvas editor widget changes == Worth refreshing the look of the editor widget, what with Krita on android and assistant undo now being a thing, - Assistants can only be selected by clicking one of their handles, if the user accidentally click-drags, they can just undo it - Only show widget for currently selected assistant - Fade out widgets for unselected assistants, but keep snapping status of the assistant (the middle button) visible - Make buttons bigger - Handles and side-handles will get displayed over faded-out widgets that belong to other assistants - Alternate action: shift-click on snapping button causes all other assistants to disable snapping, if they haven't already - Alternate action: shift-click on deletes all other assistants - Alternate action: shift-drag on moving button drags a duplicate of the assistant == More linear perspective grid/drawing assistants == The Vanishing Point assistant is incredibly useful and handy on its own already, so there's little to be gained by having a dedicated "2 Point" assistant or a "3 Point" assistant that doesn't amount to anything more than just placing 3 normal vanishing point assistants. So what I'm interested in introducing is a new set of "strict" perspective assistants that support a different kind of painting assistant workflow, where the user will be periodically tweaking the same assistant depending on what they are drawing. This workflow is in contrast to the usual one-and-done workflow where the assistant remains stationery for the rest of its useful existence. These assistants will be "strict" in the sense that the tweaks the user makes to it isn't necessarily free-form, but follows very specific rules to maintain its own coherency: - 2PP Assistant: - Dragging either VP will cause the opposite VP to move in order to maintain the relative distortion levels around the center of vision - Dragging the center of vision is restricted to the horizon. Dragging it is also not advised - https://invent.kde.org/graphics/krita/-/merge_requests/390 - https://www.geogebra.org/m/bqt5ghfn - Alternate action: Shift-drag vanishing point handle: reduce or increase size of "cone of vision", ie make VP handles closer or farther away from each other. - Alternate action: Shift-drag center of vision handle: automagically convert 2PP assistant to 3PP assistant when shift-dragging center of vision up/down - Tool Option: Toggle display of top plane / bottom plane - Tool Option: Toggle snapping towards each XYZ direction - Maybe put those toggles in RMB menu or editor widget? - 3PP Assistant: - https://www.geogebra.org/m/pcjdtny8 - TODO == Rework Perspective assistant and clean it out of the assistant tool and assistant class == I think the Perspective assistant has a very specific use-case where it is incredibly useful, and that is when you're painting a landscape and need your grass brush to resize depending on where on the assistant it is being painted on is. - Remove ability to "drag out" another Perspective assistant from the "side handles" - Consolidate as much of the Perspective assistant logic out of the assistant tool and parent assistant class and into its own assistant class - Fix the weird lagginess - Allow user to adjust how many grid squares gets drawn - Allow user to drag out side handles to enlarge the grid while keeping VPs the same == Implement framework for "grouping" assistants or making complex assistants out of simple ones == === Option 0: Brute Force === - List out every possible combination of assistants that are genuinely useful for a specific use-case or workflow - Then literally just implement a dedicated frankenstien assistant that groups those more "primitive" assistants together Examples: - 2 VPs + 1 Parallel Ruler => 2PP Assistant - 3 VPs => 3PP Assistant - 3 isometric Parallel Rulers => Isometric Drawing Assistant - 2 perpendicular Parallel Rulers => Grid Drawing Assistant === Option 1: Assistant Manager widget === - Something like the Layers docker but for assistants only - Maybe a docker? or just a table/list widget in the Tool Options - Allow multiple selection of assistants - Operations on selection of multiple assistants: - Make group - HIde group - Save group - etc === Option 2: extend the Compositions Docker === - implement Assistant Compositions: saves the state of assistant visibility and assistant snapping - or maybe a checkbox that can make a new Layer Compositions that also saves assistant visibility/snapping === Option 3: extend the Layers Docker === - Option A: implement an Assistant Layer type - Option B: allow assistants to somehow "belong" to specific layers === Option 4: Python API === - Let scripters/users can figure out themselves how they want to manage assistants - Can possibly be generalized into a Canvas Decorations API (since assistants get displayed and manipulated as a canvas decoration/guide I think)

This task is a collection of notes for several small to medium problems and possible solutions regarding painting assistants and the painting assistant tool. The idea is the consolidate all the necessary changes into a refreshed assistant tool. I feel like this is better than peppering small tweaks every minor release, and it would be a good look to have for the release of v5 :) Also perhaps it could lay the groundwork for more ambitious projects and improvements on painting assistants as a whole (eg T11345, T6543, Assistant Layers, Python API?, Animation?, etc) The motivation for this is to make Krita's assistants more useful, particularly in the perspective drawing department. My hope is for a refresh to achieve the following: - Encourage users who didn't use assistants to start using them - Encourage current users of assistants to use assistants more often than they already do - Help frequent users get more work done with assistants than they already do These notes are based on the current stable release of Krita, ~~v4.3~~ 5.0.2 (a January 2022 revision by Tiar) = The Good = Functionally, most of the assistants are perfectly usable already. These assistants probably won't receive any user-visible changes - Ruler assistants and Spline assistants - Elliptical assistants - Vanishing Point assistant = The Bad = - There ought to be some way to limit the area of effect for assistants, this will be very helpful for comic authors - https://www.davidrevoy.com/article159/design-ideas-for-a-new-krita-perspective-tool - This will mean there will be LOTS of assistants on the canvas. This needs to be easy to manage - [tiar 28.05.21] this is done here: https://invent.kde.org/graphics/krita/-/merge_requests/850 - [tiar 21.02.22] just needs to apply to all assistants, not just 2pp and vanishing points - Users want more assistants for various linear perspective drawing workflows - old ideas: https://www.davidrevoy.com/article159/design-ideas-for-a-new-krita-perspective-tool, https://bugs.kde.org/show_bug.cgi?id=405644 , https://krita-artists.org/t/proposal-for-a-1-point-perspective-assistant-tool/8377, Assistant https://krita-artists.org/t/a-2-point-perspective-assistant-tool/8227 - [tiar 28.05.21] one of the 2pp assistants has been implemented already (2vp + 1 vertical ruler which can be turned off). 3pp assistant can be *incredibly easily* made upon the 2pp assistant (the "centre of vision" replaced by 3rd vp). 1pp assistant is also needed (1vp + 2rulers), but it will need some smart drawing of the horizontal lines. - with the new 2pp assistant, 3pp can be easily done with 2pp assistant + vertical ruler turned off + one vanishing point. 1pp perspective can be done as usual: vanishing point + rulers. - Assistant control panels hiding each other and other assistants' handles https://bugs.kde.org/show_bug.cgi?id=396979 - [tiar] should be possible to do with the "editor position" in a variable instead of calculated; but it needs some smart thinking on the UI side (dragging the control panels by some recognizable icon) - No useful right-click menu unique to assistant tool -> but what should be there? [tiar 21.02.22] - No Shift-snapping during assistant creation https://bugs.kde.org/show_bug.cgi?id=406204 - No mechanism to make assistants aware of each other / stitched together / aligned to each other / etc - Will be necessary for to align 2PP and 3PP assistants together - Necessary to align Perspective assistant with VP assistant - ~~Assistant preview doesn't follow where the painting is happening on the canvas~~ <- I don't understand what that means, so maybe it's already fixed/implemented. There is only a problem for non-painting tools. [tiar 21.02.22] - Can't select multiple assistants and operate on several at once - Ugly/confusing Tool Options, especially for local assistants - 4 pixel straight line at the beginning of the painting (visible with the ellipse assistant and the spline assistant) Sumup and tasks (21.02.22): - [X] Shift-snapping during assistant creation - https://invent.kde.org/graphics/krita/-/merge_requests/414 - [ ] Make all assistants local-ized ??? - [ ] Add 3pp assistant based on 2pp one (+ local, of course), and maybe even 1pp assistant - [ ] Movable control panels for assisstants - [ ] assistants aware of each other/snapping to each other (can be turned on and off), esp. perspective + 2pp/vp - [ ] Tool Options needs to be divided into options for the currently selected assistants and for the assistant to be created. -> needs design - [ ] Select multiple assistants (with Shift, I guess) - [ ] local etc. options should work for existing assistants too (if possible) - [ ] improved system/refactoring so there is no 4 pixels straight line at the beginning = The Ugly = - Perspective Assistant: - ~~Slashes the canvas FPS if you zoom in too close https://bugs.kde.org/show_bug.cgi?id=411352 (~~fixed) - It has "side handles" that just make more Perspective assistants not aligned to anything in particular https://bugs.kde.org/show_bug.cgi?id=331787 (needs design) - Doesn't integrate with the Vanishing Point assistant https://bugs.kde.org/show_bug.cgi?id=292684 - It's logic is weirdly tangled up in the assistant tool and the painting assistant class - Doesn't do any of the cool stuff that Transform tool can do eg rotating and resizing = Proposed Changes = == Popup Palette / RMB menu == TODO (needs design) == Alternate actions== Assuming the configured alternate action key is Shift, we want specific helpful and documented things to happen when the user does the following when the assistant tool is active: - Shift-LMB-click: TODO - Shift-LMB-drag: TODO - Shift-LMB-move: TODO https://invent.kde.org/graphics/krita/-/merge_requests/414 <- accepted MR that implemented some Shift behaviour, needs to be designed thoughtfully with that in mind Suggestion: we need a way to select multiple assistants, snapping and shift-painting (like creating assistants perfectly horizontally) == Tool Options changes == Needs design. Needs to separate options for currently selected assistants and options for the new assistant (the one that will be created when the user clicks on the canvas). == On-canvas editor widget changes == Worth refreshing the look of the editor widget, what with Krita on android and assistant undo now being a thing, - Assistants can only be selected by clicking one of their handles, if the user accidentally click-drags, they can just undo it - Only show widget for currently selected assistant - Fade out widgets for unselected assistants, but keep snapping status of the assistant (the middle button) visible - Make buttons bigger - Handles and side-handles will get displayed over faded-out widgets that belong to other assistants - Alternate action: shift-click on snapping button causes all other assistants to disable snapping, if they haven't already - Alternate action: shift-click on deletes all other assistants - Alternate action: shift-drag on moving button drags a duplicate of the assistant == More linear perspective grid/drawing assistants == The Vanishing Point assistant is incredibly useful and handy on its own already, so there's little to be gained by having a dedicated "2 Point" assistant or a "3 Point" assistant that doesn't amount to anything more than just placing 3 normal vanishing point assistants. So what I'm interested in introducing is a new set of "strict" perspective assistants that support a different kind of painting assistant workflow, where the user will be periodically tweaking the same assistant depending on what they are drawing. This workflow is in contrast to the usual one-and-done workflow where the assistant remains stationery for the rest of its useful existence. These assistants will be "strict" in the sense that the tweaks the user makes to it isn't necessarily free-form, but follows very specific rules to maintain its own coherency: - [X] ~~2PP Assistant:~~ (done already) - Dragging either VP will cause the opposite VP to move in order to maintain the relative distortion levels around the center of vision - Dragging the center of vision is restricted to the horizon. Dragging it is also not advised - https://invent.kde.org/graphics/krita/-/merge_requests/390 - https://www.geogebra.org/m/bqt5ghfn - Alternate action: Shift-drag vanishing point handle: reduce or increase size of "cone of vision", ie make VP handles closer or farther away from each other. - Alternate action: Shift-drag center of vision handle: automagically convert 2PP assistant to 3PP assistant when shift-dragging center of vision up/down - Tool Option: Toggle display of top plane / bottom plane - Tool Option: Toggle snapping towards each XYZ direction - Maybe put those toggles in RMB menu or editor widget? - [ ] 3PP Assistant: - https://www.geogebra.org/m/pcjdtny8 - Tiar 21.02.22: I'm frankly not sure what to make out of it. What else do we need except for the exact same actions as 2pp + one vanishing point? (needs talking to windragon) - TODO == Rework Perspective assistant and clean it out of the assistant tool and assistant class == I think the Perspective assistant has a very specific use-case where it is incredibly useful, and that is when you're painting a landscape and need your grass brush to resize depending on where on the assistant it is being painted on is. - [ ] Remove ability to "drag out" another Perspective assistant from the "side handles" - [ ] Consolidate as much of the Perspective assistant logic out of the assistant tool and parent assistant class and into its own assistant class - [X] ~~Fix the weird lagginess~~ - [ ] Allow user to adjust how many grid squares gets drawn - [ ] Allow user to drag out side handles to enlarge the grid while keeping VPs the same == Implement framework for "grouping" assistants or making complex assistants out of simple ones == === Option 0: Brute Force === - List out every possible combination of assistants that are genuinely useful for a specific use-case or workflow - Then literally just implement a dedicated frankenstien assistant that groups those more "primitive" assistants together - This seems to be the option used in Krita since there is already a 1pp assistant (Tiar 21.02.22) Examples: - [X] 2 VPs + 1 Parallel Ruler => 2PP Assistant - [ ] 3 VPs => 3PP Assistant - [ ] 3 isometric Parallel Rulers => Isometric Drawing Assistant - [ ] 2 perpendicular Parallel Rulers => Grid Drawing Assistant === Option 1: Assistant Manager widget === - Something like the Layers docker but for assistants only - Maybe a docker? or just a table/list widget in the Tool Options - Allow multiple selection of assistants - Operations on selection of multiple assistants: - Make group - HIde group - Save group - etc === Option 2: extend the Compositions Docker === - implement Assistant Compositions: saves the state of assistant visibility and assistant snapping - or maybe a checkbox that can make a new Layer Compositions that also saves assistant visibility/snapping === Option 3: extend the Layers Docker === - Option A: implement an Assistant Layer type - Option B: allow assistants to somehow "belong" to specific layers === Option 4: Python API === - Let scripters/users can figure out themselves how they want to manage assistants - Can possibly be generalized into a Canvas Decorations API (since assistants get displayed and manipulated as a canvas decoration/guide I think) - Frankly, I think this shouldn't be an option, but just another task (Tiar 21.02.22)

This task is a collection of notes for several small to medium problems and possible solutions regarding painting assistants and the painting assistant tool. The idea is the consolidate all the necessary changes into a refreshed assistant tool. I feel like this is better than peppering small tweaks every minor release, and it would be a good look to have for the release of v5 :) Also perhaps it could lay the groundwork for more ambitious projects and improvements on painting assistants as a whole (eg T11345, T6543, Assistant Layers, Python API?, Animation?, etc) The motivation for this is to make Krita's assistants more useful, particularly in the perspective drawing department. My hope is for a refresh to achieve the following: - Encourage users who didn't use assistants to start using them - Encourage current users of assistants to use assistants more often than they already do - Help frequent users get more work done with assistants than they already do These notes are based on the current stable release of Krita, v4.3 = The Good = Functionally, most of the assistants are perfectly usable already. These assistants probably won't receive any user-visible changes - Ruler assistants and Spline assistants - Elliptical assistants - Vanishing Point assistant = The Bad = - There ought to be some way to limit the area of effect for assistants, this will be very helpful for comic authors - https://www.davidrevoy.com/article159/design-ideas-for-a-new-krita-perspective-tool - This will mean there will be LOTS of assistants on the canvas. This needs to be easy to manage - [tiar 28.05.21] this is done here: https://invent.kde.org/graphics/krita/-/merge_requests/850 - Users want more assistants for various linear perspective drawing workflows - 2PP Assistant https://bugs.kde.org/show_bug.cgi?id=405644 - 1PP Assistant https://krita-artists.org/t/proposal-for-a-1-point-perspective-assistant-tool/8377 - Yet another 2PP Assistant https://krita-artists.org/t/a-2-point-perspective-assistant-tool/8227 - I want a 3PP assistant - [tiar 28.05.21] one of the 2pp assistants has been implemented already (2vp + 1 vertical ruler which can be turned off). 3pp assistant can be *incredibly easily* made upon the 2pp assistant (the "centre of vision" replaced by 3rd vp). 1pp assistant is also needed (1vp + 2rulers), but it will need some smart drawing of the horizontal lines. - with the new 2pp assistant, 3pp can be easily done with 2pp assistant + vertical ruler turned off + one vanishing point. 1pp perspective can be done as usual: vanishing point + rulers. - Assistant control panels hiding each other and other assistants' handles https://bugs.kde.org/show_bug.cgi?id=396979 - [tiar] should be possible to do with the "editor position" in a variable instead of calculated; but it needs some smart thinking on the UI side (dragging the control panels by some recognizable icon) - No useful right-click menu unique to assistant tool - No Shift-snapping during assistant creation https://bugs.kde.org/show_bug.cgi?id=406204 - No mechanism to make assistants aware of each other / stitched together / aligned to each other / etc - Will be necessary for to align 2PP and 3PP assistants together - Necessary to align Perspective assistant with VP assistant - Assistant preview doesn't follow where the painting is happening on the canvas - [tiar] I think this has been fixed... - Can't select multiple assistants and operate on several at once = The Ugly = - Perspective Assistant: - Slashes the canvas FPS if you zoom in too close https://bugs.kde.org/show_bug.cgi?id=411352 - It has "side handles" that just make more Perspective assistants not aligned to anything in particular https://bugs.kde.org/show_bug.cgi?id=331787 - Doesn't integrate with the Vanishing Point assistant https://bugs.kde.org/show_bug.cgi?id=292684 - It's logic is weirdly tangled up in the assistant tool and the painting assistant class - Doesn't do any of the cool stuff that Transform tool can do eg rotating and resizing = Proposed Changes = == Popup Palette / RMB menu == TODO == Alternate actions== Assuming the configured alternate action key is Shift, we want specific helpful and documented things to happen when the user does the following when the assistant tool is active: - Shift-LMB-click: TODO - Shift-LMB-drag: TODO - Shift-LMB-move: TODO https://invent.kde.org/graphics/krita/-/merge_requests/414 == Tool Options changes == TODO == On-canvas editor widget changes == Worth refreshing the look of the editor widget, what with Krita on android and assistant undo now being a thing, - Assistants can only be selected by clicking one of their handles, if the user accidentally click-drags, they can just undo it - Only show widget for currently selected assistant - Fade out widgets for unselected assistants, but keep snapping status of the assistant (the middle button) visible - Make buttons bigger - Handles and side-handles will get displayed over faded-out widgets that belong to other assistants - Alternate action: shift-click on snapping button causes all other assistants to disable snapping, if they haven't already - Alternate action: shift-click on deletes all other assistants - Alternate action: shift-drag on moving button drags a duplicate of the assistant == More linear perspective grid/drawing assistants == The Vanishing Point assistant is incredibly useful and handy on its own already, so there's little to be gained by having a dedicated "2 Point" assistant or a "3 Point" assistant that doesn't amount to anything more than just placing 3 normal vanishing point assistants. So what I'm interested in introducing is a new set of "strict" perspective assistants that support a different kind of painting assistant workflow, where the user will be periodically tweaking the same assistant depending on what they are drawing. This workflow is in contrast to the usual one-and-done workflow where the assistant remains stationery for the rest of its useful existence. These assistants will be "strict" in the sense that the tweaks the user makes to it isn't necessarily free-form, but follows very specific rules to maintain its own coherency: - 2PP Assistant: - Dragging either VP will cause the opposite VP to move in order to maintain the relative distortion levels around the center of vision - Dragging the center of vision is restricted to the horizon. Dragging it is also not advised - https://invent.kde.org/graphics/krita/-/merge_requests/390 - https://www.geogebra.org/m/bqt5ghfn - Alternate action: Shift-drag vanishing point handle: reduce or increase size of "cone of vision", ie make VP handles closer or farther away from each other. - Alternate action: Shift-drag center of vision handle: automagically convert 2PP assistant to 3PP assistant when shift-dragging center of vision up/down - Tool Option: Toggle display of top plane / bottom plane - Tool Option: Toggle snapping towards each XYZ direction - Maybe put those toggles in RMB menu or editor widget? - 3PP Assistant: - https://www.geogebra.org/m/pcjdtny8 - TODO == Rework Perspective assistant and clean it out of the assistant tool and assistant class == I think the Perspective assistant has a very specific use-case where it is incredibly useful, and that is when you're painting a landscape and need your grass brush to resize depending on where on the assistant it is being painted on is. - Remove ability to "drag out" another Perspective assistant from the "side handles" - Consolidate as much of the Perspective assistant logic out of the assistant tool and parent assistant class and into its own assistant class - Fix the weird lagginess - Allow user to adjust how many grid squares gets drawn - Allow user to drag out side handles to enlarge the grid while keeping VPs the same == Implement framework for "grouping" assistants or making complex assistants out of simple ones == === Option 0: Brute Force === - List out every possible combination of assistants that are genuinely useful for a specific use-case or workflow - Then literally just implement a dedicated frankenstien assistant that groups those more "primitive" assistants together Examples: - 2 VPs + 1 Parallel Ruler => 2PP Assistant - 3 VPs => 3PP Assistant - 3 isometric Parallel Rulers => Isometric Drawing Assistant - 2 perpendicular Parallel Rulers => Grid Drawing Assistant === Option 1: Assistant Manager widget === - Something like the Layers docker but for assistants only - Maybe a docker? or just a table/list widget in the Tool Options - Allow multiple selection of assistants - Operations on selection of multiple assistants: - Make group - HIde group - Save group - etc === Option 2: extend the Compositions Docker === - implement Assistant Compositions: saves the state of assistant visibility and assistant snapping - or maybe a checkbox that can make a new Layer Compositions that also saves assistant visibility/snapping === Option 3: extend the Layers Docker === - Option A: implement an Assistant Layer type - Option B: allow assistants to somehow "belong" to specific layers === Option 4: Python API === - Let scripters/users can figure out themselves how they want to manage assistants - Can possibly be generalized into a Canvas Decorations API (since assistants get displayed and manipulated as a canvas decoration/guide I thinkThese notes are based on the current stable release of Krita, ~~v4.3~~ 5.0.2 (a January 2022 revision by Tiar) = The Good = Functionally, most of the assistants are perfectly usable already. These assistants probably won't receive any user-visible changes - Ruler assistants and Spline assistants - Elliptical assistants - Vanishing Point assistant = The Bad = - There ought to be some way to limit the area of effect for assistants, this will be very helpful for comic authors - https://www.davidrevoy.com/article159/design-ideas-for-a-new-krita-perspective-tool - This will mean there will be LOTS of assistants on the canvas. This needs to be easy to manage - [tiar 28.05.21] this is done here: https://invent.kde.org/graphics/krita/-/merge_requests/850 - [tiar 21.02.22] just needs to apply to all assistants, not just 2pp and vanishing points - Users want more assistants for various linear perspective drawing workflows - old ideas: https://www.davidrevoy.com/article159/design-ideas-for-a-new-krita-perspective-tool, https://bugs.kde.org/show_bug.cgi?id=405644 , https://krita-artists.org/t/proposal-for-a-1-point-perspective-assistant-tool/8377, Assistant https://krita-artists.org/t/a-2-point-perspective-assistant-tool/8227 - [tiar 28.05.21] one of the 2pp assistants has been implemented already (2vp + 1 vertical ruler which can be turned off). 3pp assistant can be *incredibly easily* made upon the 2pp assistant (the "centre of vision" replaced by 3rd vp). 1pp assistant is also needed (1vp + 2rulers), but it will need some smart drawing of the horizontal lines. - with the new 2pp assistant, 3pp can be easily done with 2pp assistant + vertical ruler turned off + one vanishing point. 1pp perspective can be done as usual: vanishing point + rulers. - Assistant control panels hiding each other and other assistants' handles https://bugs.kde.org/show_bug.cgi?id=396979 - [tiar] should be possible to do with the "editor position" in a variable instead of calculated; but it needs some smart thinking on the UI side (dragging the control panels by some recognizable icon) - No useful right-click menu unique to assistant tool -> but what should be there? [tiar 21.02.22] - No Shift-snapping during assistant creation https://bugs.kde.org/show_bug.cgi?id=406204 - No mechanism to make assistants aware of each other / stitched together / aligned to each other / etc - Will be necessary for to align 2PP and 3PP assistants together - Necessary to align Perspective assistant with VP assistant - ~~Assistant preview doesn't follow where the painting is happening on the canvas~~ <- I don't understand what that means, so maybe it's already fixed/implemented. There is only a problem for non-painting tools. [tiar 21.02.22] - Can't select multiple assistants and operate on several at once - Ugly/confusing Tool Options, especially for local assistants - 4 pixel straight line at the beginning of the painting (visible with the ellipse assistant and the spline assistant) Sumup and tasks (21.02.22): - [X] Shift-snapping during assistant creation - https://invent.kde.org/graphics/krita/-/merge_requests/414 - [ ] Make all assistants local-ized ??? - [ ] Add 3pp assistant based on 2pp one (+ local, of course), and maybe even 1pp assistant - [ ] Movable control panels for assisstants - [ ] assistants aware of each other/snapping to each other (can be turned on and off), esp. perspective + 2pp/vp - [ ] Tool Options needs to be divided into options for the currently selected assistants and for the assistant to be created. -> needs design - [ ] Select multiple assistants (with Shift, I guess) - [ ] local etc. options should work for existing assistants too (if possible) - [ ] improved system/refactoring so there is no 4 pixels straight line at the beginning = The Ugly = - Perspective Assistant: - ~~Slashes the canvas FPS if you zoom in too close https://bugs.kde.org/show_bug.cgi?id=411352 (~~fixed) - It has "side handles" that just make more Perspective assistants not aligned to anything in particular https://bugs.kde.org/show_bug.cgi?id=331787 (needs design) - Doesn't integrate with the Vanishing Point assistant https://bugs.kde.org/show_bug.cgi?id=292684 - It's logic is weirdly tangled up in the assistant tool and the painting assistant class - Doesn't do any of the cool stuff that Transform tool can do eg rotating and resizing = Proposed Changes = == Popup Palette / RMB menu == TODO (needs design) == Alternate actions== Assuming the configured alternate action key is Shift, we want specific helpful and documented things to happen when the user does the following when the assistant tool is active: - Shift-LMB-click: TODO - Shift-LMB-drag: TODO - Shift-LMB-move: TODO https://invent.kde.org/graphics/krita/-/merge_requests/414 <- accepted MR that implemented some Shift behaviour, needs to be designed thoughtfully with that in mind Suggestion: we need a way to select multiple assistants, snapping and shift-painting (like creating assistants perfectly horizontally) == Tool Options changes == Needs design. Needs to separate options for currently selected assistants and options for the new assistant (the one that will be created when the user clicks on the canvas). == On-canvas editor widget changes == Worth refreshing the look of the editor widget, what with Krita on android and assistant undo now being a thing, - Assistants can only be selected by clicking one of their handles, if the user accidentally click-drags, they can just undo it - Only show widget for currently selected assistant - Fade out widgets for unselected assistants, but keep snapping status of the assistant (the middle button) visible - Make buttons bigger - Handles and side-handles will get displayed over faded-out widgets that belong to other assistants - Alternate action: shift-click on snapping button causes all other assistants to disable snapping, if they haven't already - Alternate action: shift-click on deletes all other assistants - Alternate action: shift-drag on moving button drags a duplicate of the assistant == More linear perspective grid/drawing assistants == The Vanishing Point assistant is incredibly useful and handy on its own already, so there's little to be gained by having a dedicated "2 Point" assistant or a "3 Point" assistant that doesn't amount to anything more than just placing 3 normal vanishing point assistants. So what I'm interested in introducing is a new set of "strict" perspective assistants that support a different kind of painting assistant workflow, where the user will be periodically tweaking the same assistant depending on what they are drawing. This workflow is in contrast to the usual one-and-done workflow where the assistant remains stationery for the rest of its useful existence. These assistants will be "strict" in the sense that the tweaks the user makes to it isn't necessarily free-form, but follows very specific rules to maintain its own coherency: - [X] ~~2PP Assistant:~~ (done already) - Dragging either VP will cause the opposite VP to move in order to maintain the relative distortion levels around the center of vision - Dragging the center of vision is restricted to the horizon. Dragging it is also not advised - https://invent.kde.org/graphics/krita/-/merge_requests/390 - https://www.geogebra.org/m/bqt5ghfn - Alternate action: Shift-drag vanishing point handle: reduce or increase size of "cone of vision", ie make VP handles closer or farther away from each other. - Alternate action: Shift-drag center of vision handle: automagically convert 2PP assistant to 3PP assistant when shift-dragging center of vision up/down - Tool Option: Toggle display of top plane / bottom plane - Tool Option: Toggle snapping towards each XYZ direction - Maybe put those toggles in RMB menu or editor widget? - [ ] 3PP Assistant: - https://www.geogebra.org/m/pcjdtny8 - Tiar 21.02.22: I'm frankly not sure what to make out of it. What else do we need except for the exact same actions as 2pp + one vanishing point? (needs talking to windragon) - TODO == Rework Perspective assistant and clean it out of the assistant tool and assistant class == I think the Perspective assistant has a very specific use-case where it is incredibly useful, and that is when you're painting a landscape and need your grass brush to resize depending on where on the assistant it is being painted on is. - [ ] Remove ability to "drag out" another Perspective assistant from the "side handles" - [ ] Consolidate as much of the Perspective assistant logic out of the assistant tool and parent assistant class and into its own assistant class - [X] ~~Fix the weird lagginess~~ - [ ] Allow user to adjust how many grid squares gets drawn - [ ] Allow user to drag out side handles to enlarge the grid while keeping VPs the same == Implement framework for "grouping" assistants or making complex assistants out of simple ones == === Option 0: Brute Force === - List out every possible combination of assistants that are genuinely useful for a specific use-case or workflow - Then literally just implement a dedicated frankenstien assistant that groups those more "primitive" assistants together - This seems to be the option used in Krita since there is already a 1pp assistant (Tiar 21.02.22) Examples: - [X] 2 VPs + 1 Parallel Ruler => 2PP Assistant - [ ] 3 VPs => 3PP Assistant - [ ] 3 isometric Parallel Rulers => Isometric Drawing Assistant - [ ] 2 perpendicular Parallel Rulers => Grid Drawing Assistant === Option 1: Assistant Manager widget === - Something like the Layers docker but for assistants only - Maybe a docker? or just a table/list widget in the Tool Options - Allow multiple selection of assistants - Operations on selection of multiple assistants: - Make group - HIde group - Save group - etc === Option 2: extend the Compositions Docker === - implement Assistant Compositions: saves the state of assistant visibility and assistant snapping - or maybe a checkbox that can make a new Layer Compositions that also saves assistant visibility/snapping === Option 3: extend the Layers Docker === - Option A: implement an Assistant Layer type - Option B: allow assistants to somehow "belong" to specific layers === Option 4: Python API === - Let scripters/users can figure out themselves how they want to manage assistants - Can possibly be generalized into a Canvas Decorations API (since assistants get displayed and manipulated as a canvas decoration/guide I think) - Frankly, I think this shouldn't be an option, but just another task (Tiar 21.02.22)