kImageAnnotator icon indicating copy to clipboard operation
kImageAnnotator copied to clipboard

Permit "temporal switch" to select (when drawing items)

Open vaunchag opened this issue 3 years ago • 1 comments

I completely agree with the problem addressed with #155 (and also the convenience of #161). But...

Problem

Now that it is implemented and I have tested it, I think that it doesn't address profoundly the issue:

  • It is true that many times after putting an element, you want to (or need to) adjust it.
  • But very often, you don't need to (specially when you become a more "proficient annotator"). And most of these other times, you want to repeat the last tool used.

I overcame this by learning and using the keyboard shortcuts (starting with "s")... Currently implemented "global decision" with #155 and #161 avoids the need to know the "s" shortcut. But that one is the "easy one" (always the same). It then "leaves you alone" for the usual case of "coming back" to the last tool: you need to learn the other shortcuts, and then each time recall them.

Proposed solution (for keyboard)

I think there is a better way. The ideal would be to be able to retain the last non-select tool, but with something permitting a temporal use of the select tool.

I can think of these different ways of implementing it with keyboard:

  1. A new "toggle select" shortcut key: press to temporally select, press again to come back to the last used tool.
  2. Like 1., but abusing current "s" shortcut as toggle: if pressed when already in select mode, it comes back to the last non-select tool used.
  3. A new "non-toggle" shortcut key to "last non-select tool". In this case, the use of this shortcut would have to be alternated with the "s" shortcut (for going and coming back from select).
  4. A modifier key (ctrl, shift, alt, ...) that while pressed activates the "select mode".

Comparing the proposed options

I see problems with 4: it could overlap with other (current of future) modifiers that may be used for the drawing tools (force square/circle, force straight lines in 45º steps, ...). Also, constantly pressing something while using the mouse is not ideal.

I also see 3 less handy than 1 or 2: I prefer having one single key (finger can remain nearby) than having to alternate between 2 shortcuts. If 3 is decided, I would at least prefer a key close to the "s" ("q" and "z" seem currently available, although this is assuming qwerty/azerty keyboard layouts).

I also see 2 (enhancing current "s") possibly confusing for users. If choosing this way, it probably should be made globally configurable (and probably deactivated by default).

All of the solutions avoid the current need to know the shortcuts of the different tools in order to work quick in the usual case (that is repeating last tool). And even when knowing the shortcuts (or the most used ones), these solutions reduce considerably the cognitive load (and slowness) for the usual case: recalling each time which is the tool I'm using, then recalling its shortcut or hunting its button with the mouse.

Mouse use

In fact, this feature could also benefit the "mouse only" use. Options I see here:

  1. New button for this. But not sure of an intuitive icon, and also this adds clutter to the UI.
  2. Reusing current select UI button: if already pressed, unselects it and switches to select the last selected tool. This looks quite intuitive.

With these, one presses (even with the mouse) sistematically at the same place (vs. each time thinking of the last tool used, then hunting it). With touch interfaces (whoever uses 2-in-1 laptops), one can even keep a finger ready there, always at the same place. The additional cognitive load is only needed when needing a real tool change (since selecting is not really a tool change).

Summary (global proposed solution)

  • For mouse actions, enhancing current select button to toggle to the last tool seems quite harmless and intuitive (provides an unavoidable visual feedback).
  • Then, for keyboard, implementing one of these (in my prefered order):
    • 1 : Use a new toggle key: even if slightly different from the mouse action, it is potentially less confusing (one knows that he is pressing a special "toggle" key).
    • 2 : Use "s" as toggle. It then will work exactly as the mouse button (good), but when pressing the key there is not an unavoidable visual feedback of what happens. Accidental double press will be confusing (specially if one does not know the feature). This possibly obliges to bury this feature in a non-default config option, a shame.
    • 3 : Use a new non-toggle key for "last non-select tool": no surprises, but obliges to alternate between two keys, this one and the "s" (please: in that case put them close). If 2 is implemented as a non default global config to be activated, maybe I prefer this option 3 than 2.

PS

For the keyboard use, I have discarded a different possibility:

An "alt+tab"-style shortcut to cycle through last selected tools, including select.

This would permit also other use cases like alternating between 2 drawing tools that are usually alternated (not limiting the other one to the select tool), and even potentially more than 2 (as alt+tab does).

But:

  • The recently implemented "double tools" (arrow + other) cover soundly most of the common use cases.
  • If one additionally wants to rectify with select, this becomes a third tool to cycle. "Alt-tabbing" between more than 2 things is, I think, only for die-hards or shaolin monks.

Anyway, a functionality "toggle between the two last used tools (not including select tool)" may be still interesting, but implemented separatedly of the one requested here. It would be different shortcut (no need to be alt+tab-like, could be a normal toggle one). This could be indeed a different FR.

vaunchag avatar Jan 05 '21 13:01 vaunchag

Sorry for the verbosity. After a re-thought, I have come to (I think) a more convincing implementation proposal:

Using a secondary mouse button (middle-click) for triggering temporal resizing/replacement.

It covers both mouse and keyboard use cases. It is in fact a mouse-only solution for something that should essentially remain mouse related if at all possible: draw a shape, then optionally adjust it, then draw a new shape (often of the same kind), ...

Curiously: at present in Ksnip, a right-single-click over a shape triggers also its selection, and thus the ability to adjust it. But:

  • One has also the context menu triggered: not clean.
  • One fully enters in select mode: after adjusting, one needs to re-select a tool. So this only avoids having to press "s" or having to go to the toolbar to click the select button.

Right-click should remain as it is (a context menu). But middle-single-click is currently free, so the implementation could be:

  • Middle-single-click on any shape triggers its temporal selection.
  • Then, left-click-and-drag acts on the selected shape "as normal": if done on a handler, we resize; if done elsewhere on the shape, we move it.
  • But this is a temporal selection: a further left-single-click (or left-click-and-drag) that is not in that temporarily selected shape will trigger the drawing of a new shape (using the currently -or last, depending on implementation- selected shape tool).

I have the intuition that this might not be very difficult to implement (but I don't know for sure). I'm not sure if it is worth to give visual feedback that this is a "temporal" and not normal selection, e.g. with different color or handler icons (possibly not necessary).

Note: It could be tempting to permit a midle-click-and-drag after selection for moving/resizing (using the same button used for temporal selection, instead of "changing" to the first button use). But this conflicts with the usual feature of middle-click-and-drag for panning (that currently Ksnip is soundly implementing). At most, we could decide that in "temporal selection mode", the panning is overriden by this... but this is risky: handy panning is a fundamental need at every moment.

Note: even though ksnip does not use currently the middle-single-click, I think it will have a usabilty issue here. Currently, if the button is not pressed very neutrally (at least with my mouse), it is easy to trigger at the same time a slight zoom-in (or out). More critically, during middle-click-and-drag (for panning), it is even more easy to trigger that (so it pans and slightly zooms). Other tools (e.g. Inkscape) avoid completely this problem by ignoring wheel movement during middle-single-click or middle-click-and-drag. I mention it here (and not in a separate issue) because it is related with the proposed implementation: in general, middle-click shouldn't trigger unwanted zooms.

I also had a quick look to other popular vector drawing tools, to see how they handle this stuff:

  • LibreOffice Impress, Google Slides, both imitating industry standard Powerpoint: after each shape is drawn, they switch back to select mode. Popular, but sub-optimal.
  • Inkscape, Shutter, both maybe (this is my guess) imitating industry standard Adobe Illustrator: the chosen tool remains after a shape is drawn. But here, the last drawn shape offers handles for on-the-fly resizing (without loosing the tool). Unfortunately, they do not permit also on-the-fly moving (without loosing the tool). Note: Gimp does not allow much vectorial objects ("shapes"), but for inserted text it works as Inkscape (easy on-the-fly resizing without loosing the tool). Not sure about Photoshop.

Ksnip could also offer the handles for the last drawn shape, permiting directly resizing it and without loosing current tool. Moreover: contrary to Inskcape, ksnip could also permit moving that last shape if clicking and dragging on it in a different place that its handles. Why not? This sacrifices some corner use cases (e.g. new shape that starts on the border of the previous one, or new filled shape starting inside the previous filled shape)... but can be well worth it. Most of the corner cases can be easily avoided by starting the new shape elsewhere, and in any case moving a last created shape is a much more usual case.

In short: the proposed "temporal selection" could also be systematically triggered on the last drawn shape. This is very intuitive, and will save often clicks.

Note that this is complementary to a "temporal selection" explicitly triggered with middle-single-click: that one permits quickly resizing or moving any previously drawn shape, without "loosing focus" (loosing current selected tool). In my experience, these adjustments are often need on-the-fly for "making room" for a new shape.

Note: Inkscape and other use the middle-single-click for "one-step zoom-in". But I find this quite redundant with the scrollwheel, thus can easily be sacrified. At most, if some day this is made into Ksnip, it can reasonably be only triggered when middle-clicking in an empty space (with middle-clicking on any shape still triggering its "temporal selection").

vaunchag avatar Jan 05 '21 20:01 vaunchag