-
-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Permit "temporal switch" to select (when drawing items) #194
Comments
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:
Right-click should remain as it is (a context menu). But middle-single-click is currently free, so the implementation could be:
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:
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"). |
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:
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:
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:
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)
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:
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.
The text was updated successfully, but these errors were encountered: