Skip to content

Draft: Switch to the next appropriate tool when the user confirms the action

Starting from the need to switch to the most useful tool when pressing ENTER after "Paste into Active Layer" or "Paste as Reference Image", I'm trying a solution that has a consistent logic and may be useful for a number of other use cases listed in the Test Plan.

I thus created a categorization of tools, where each tool may sometime fit more than one category.

At the moment, this categorization is only used for implementing the logic of automatic tool switching on completion, and which tool belongs to each category may be tweaked down the line. There is also a flag to denote tools that use the brush settings. Another set of flags determines if the tool affects shapes, pixels, or none of them.

In the code, this categorization is separate from the toolbox section, even though there is some overlap. After reviewing the existing suggestions around the toolbox redesign at https://krita-artists.org/t/toolbox-docker-redesign/7692, these categories may also overlap with some of the discussion there.

The main categories are:

  1. Creation (paint, fill, smart patch, text, ...). They affect the image.
  2. Selection (for pixels or shapes). Pixel selection directly affects Creation afterwards.
  3. Transform (of selections, layers, or shapes). They use the Selection and affect the image.
  4. Guide (color sampler, reference images, assistants). They don't affect the image.
  5. Navigation (pan and zoom). They are useful temporarily while using other tools.

When using a tool of one category, the next tool is the most recently used one in any of the categories above it. This creates a flow, so each time ENTER is pressed, we always move "closer" to tools that paint on the canvas.

I made an exception for tools that work exclusively on shapes, keeping the current logic when ENTER is pressed. This is because the default on new pixel layers is to paint, while the default on new vector layers is to select. It might make sense to activate a vector paint tool (such as Freehand Path) on empty vector layers, but this is not something that I'm changing here for now.

You can still go back to a vector tool when pressing ENTER from the other ones, for example going from Transform to Select Shapes.

Test Plan

Use case of switching back after an automatic tool activation:

  1. Select any paint tool and use it
  2. Make a selection and copy it to the clipboard
  3. Use (a) "Paste into Active Layer" or (b) "Paste as Reference Image"
  4. Press ENTER. This should switch to the last used selection tool.
  5. Press ENTER again. This should switch to the last used paint tool.

Use case of transforming a layer:

  1. Select any paint tool and use it
  2. Select the "Move" tool or press "T"
  3. Move the layer and press ENTER. This should switch to the last used paint tool.

Use case of transforming selections:

  1. Use the freehand selection or another selection tool on a painted area
  2. Right click and select "Transform" > "Transform Tool"
  3. Move the selection and press ENTER. This should switch back to the selection tool.

Use case of painting within masks:

  1. Select the Fill tool or the Brush tool without using it yet
  2. Use the freehand selection or another selection tool
  3. Press ENTER. This should go back to the correct tool, ready to paint within the selection.

Use case of auxiliary tools:

  1. At any point before pressing ENTER or pasting in the tests above, use the Assistant tool
  2. Press ENTER. This should switch to the tool that was previously being used.
  3. When ENTER is pressed again, it should activate the relevant next tool, not the Assistant tool.

Use case of pan and zoom:

  1. At any point in the tests above, use the Pan and the Zoom tools, and switch between them
  2. When ENTER is pressed, the last used tool should be selected.

Unit Tests

The following tests failed, although probably because of other commits:

	163 - libs-image-kis_asl_layer_style_serializer_test (Child aborted)
	164 - libs-image-TestAslStorage (Failed)
	219 - libs-libkis-TestDocument (Child aborted)

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (See above.)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.
Edited by Paolo Amadini

Merge request reports