Use case

for all these things:

• inserting text
• drawing free shape or polygon
• 2-steps curves
• rotating
• skew
• ...?

it's not clear that the preview is indeed just a preview

Suggested solution

• ensure there is always an accurate edition status (get_editing_tips)
• consistently apply previews by default instead of canceling them when the tool changes
• [ ] consistently apply previews by default instead of whatever happens when the tab changes (see issues Ghost selection when working with several tabs #580 )
• redesign the text tool:
  • [ ] [optional] entry with custom css directly on the layout?? The point of a GtkLayout is to put widgets on it #4
  • area around that text (with margin and dashed outline) to move it
    • manage the pointer on hover 😔
    • keep a consistent margin regardless of the zoom level 😔
  • clicking outside this outline confirms the insertion
  • auto-refresh the preview when options changes
  • accurate edition status, again, explaining what to do, where to click, etc.
• split "what needs to happen tool-wide when options change" away from the get_editing_tips tool method, so the preview always has accurate options
  • implement this split for all tools
    • text (as already mentioned)
    • arc
    • pencil, points, paint, line, highlight, eraser, brush (no preview, just updating internal values)
    • shape
    • [ ] all select tools quite hard, see Selection options applied when defining it, not changeable afterwards #583
    • crop
    • filters
    • [ ] rotate doesn't apply to this tool
    • scale
    • skew
  • include the tool thickness
  • include the tool color(s)
  • stop doing any update to options' values in on_press_on_area

Possible drawbacks

too many editing status would defeat their own point #567

likely not possible everywhere (edit: yes #583)

i should have a better framework to track what the pointer is hovering, otherwise it'll always look awful