Re: [Inkscape-devel] NEW: touch selection
On 2007-April-14 , at 01:08 , bulia byak wrote:
On 4/13/07, jiho <jo.irisson@...400...> wrote:
Indeed, it seems the selector tool is out of modifiers. In fact there is already a conflict: you used ALT for touch selection which steels it from "Select under".
Nope, it was just a bug that I just found myself and fixed :) Alt+click selects under, Alt+drag selects by touch. No conflict here. Should work properly now, please test.
That was quick!
[...]
I am studying keys.svg and trying to come up with a decent solution but I guess there is a point when a toggle will be needed to accommodate for different sets of behaviors.
Maybe... but I'll keep trying :)
OK, so I have some more meat for you to bite in then ;) I studied keys.svg and experimented with a test drawing (http:// jo.irisson.free.fr/dropbox/selection_test_case.svg) and I concluded that the current behavior is:
Clic = selects Shift+clic = toggles selection Ctrl+clic = selects within group Alt+clic = selects under Ctrl+Alt+clic = when the selection is empty, first selects in group and then further clics select under, through the group and possibly underneath ; when a group is already selected, selects underneath it without entering the group Shift+Ctrl+clic = toggles selection, entering in groups Shift+Ctrl+Alt+clic = when the selection is empty, adds to selection, then adds to selection underneath (entering in groups), and then toggles the selection of the front most object ; when a group is already selected, adds to selection under the selected group, then adds to selection underneath (entering in groups if necessary), and then toggles the selection of the front most object ; (wow that was complex... and not very useful probably)
Drag = select what is inside Shift+Drag = add to selection what is inside Ctrl+Drag = move object hor/ver when selection not empty ; select first touched object and moves hor/ver when selection empty Alt+Drag = move object when selection not empty ; touch selection when selection empty Shift+Ctrl+Drag = identical to Ctrl+Drag Ctrl+Alt+Drag = move object hor/ver when selection not empty ; does nothing on empty selections Shift+Ctrl+Alt+Drag = idem (move object hor/ver when selection not empty ; does nothing on empty selections)
I think I was exhaustive. Most of it is really great (for me, one of Inkscape main strengths) but some details could be improved which would leave room for even greater improvements!
Proposed changes: => Ctrl+Alt+clic should display the first described behavior, even there is a group selected first (this would probably make things work the same for Shift+Ctrl+Alt+clic also). I think it is more consistent with the idea that Ctrl selects inside groups and does not contradict the idea that alt selects underneath the currently selected object => Shift+Drag should _toggle_ the selection of what is inside the selection rectangle and not just add. I cannot count the times when I would have had the use for this behavior in the past. In addition it is more consistent with Shift+clic toggle behavior. => Ctrl+Drag and Shift+Ctrl+Drag behavior is strange when the selection is empty, I think it could (should?) do nothing => similarly Alt+Drag behavior is odd when the selection is not empty. IMHO, Alt+Drag should always draw a scribble selection path now. It is more useful. (=> It would be nice if scribble paths could have the same visual aspects as rect selections)
And in the end, long term improvement: => Create full "contact" and "encircle" selection modes: . In encircle mode rect selections behave as now, scribble selection paths are automatically closed and only objects inside are selected (i.e. lasso tool) . In contact mode, rect selection behave as in AI, scribble selections paths are left as is (i.e. not closed) and behave as now Switching between the two would be most convenient through a modifier key. If the last two changes above are done, Ctrl+drag and Ctrl+Alt +drag are freed and could be used. If we consider that Ctrl switches to contact mode, we have: Ctrl+drag = contact rect selection and Ctrl +Alt+drag = contact scribble selection, and Alt+drag becomes encircle scribble selection. Otherwise, this could be achieved via a toggle (shortcut: m for "selection Mode", can't find a better one). The "issue" with this is that rect selection is probably more useful in encircle mode while scribble selection is probably more useful in contact mode so the toggle state should be independent for these two selection types (so that is is possible to switch from encircling-rect-mode to contact- scribble-mode by just pressing Alt, without having to pass through m- Alt-scribble-m).
What do you think?
JiHO --- http://jo.irisson.free.fr/
On 4/13/07, jiho <jo.irisson@...400...> wrote:
Proposed changes: => Ctrl+Alt+clic should display the first described behavior, even there is a group selected first (this would probably make things work the same for Shift+Ctrl+Alt+clic also). I think it is more consistent with the idea that Ctrl selects inside groups and does not contradict the idea that alt selects underneath the currently selected object
This would make it more complex. One of the ways to test a proposed change is to put yourself into the documentation writer's shoes and see if this change can be easily explained to the user. In this case, we'll have to repeat all existing explanations (already quite complex!) and then add, "except when the selected object is a group, in which case blah blah ..." It will likely terminally confuse a reader who somehow got as far as "except when".
On the other hand, what is the big benefit? You can get the same result by Ctrl+click and Ctrl+Alt+clicking in succession.
=> Shift+Drag should _toggle_ the selection of what is inside the selection rectangle and not just add. I cannot count the times when I would have had the use for this behavior in the past. In addition it is more consistent with Shift+clic toggle behavior.
Also disagree. I think the toggle behavior is only acceptable for a single object where you clearly see its current status. With bulk operations, it would be a disaster. I often do several shift+drags when I want to include many small objects in selection - and as a rule, my drags _overlap_ "just in case" so I don't miss anything. With yout proposal, overlapped areas will be deselected back - which will be a royal mess.
What we need instead is a unconditional "subtract from selection" (not toggle!) mode for rubberband and touch selection. But we've absolutely run out of keyboard shortcuts for this :(
=> Ctrl+Drag and Shift+Ctrl+Drag behavior is strange when the selection is empty, I think it could (should?) do nothing
Why? It just works consistently the same as simple drag: selects the object where you started dragging and then moves it. That is, does "click and drag", not just "drag". The only logical difference is that with Ctrl it selects in groups (as you would expect).
=> similarly Alt+Drag behavior is odd when the selection is not empty. IMHO, Alt+Drag should always draw a scribble selection path now. It is more useful.
Alt+dragging selection is useful too. Imagine you selected under some object completely covered by other objects and want to move it. I would probably use arrow keys, but not everyone is comfortable using them; many people prefer to drag by mouse. But you can't simply drag it - that will select the object on top of it. This is where Alt+drag comes to the rescue.
Besides, this is somewhat similar to how the regular drag works. It also does not always start rubberband, but only if you start dragging from an empty space; otherwise it moves objects. To force a rubberband in documents where you don't have any empty space, there's a trick: press Shift and start dragging, this will always give you the rubberband. Exactly the same trick works with touch selection: dragging with Alt+Shift will always give you touchpath even if you have selection. (Though in both cases, Shift will have a side effect of adding to the selection, not replacing it, so it's always a good idea to Esc the existing selection beforehand.)
(=> It would be nice if scribble paths could have the same visual aspects as rect selections)
Yes. I will look into this. The problem is that canvas paths use a different compositing operator than canvas rects...
And in the end, long term improvement: => Create full "contact" and "encircle" selection modes: . In encircle mode rect selections behave as now, scribble selection paths are automatically closed and only objects inside are selected (i.e. lasso tool) . In contact mode, rect selection behave as in AI,
To be honest, I wrote the touch selection exactly so that I'm no longer bothered by requests to do the AI mode :) I really find it rather strange. A rectangle is, by its very nature, something encircling. Forcing it to do both encircling and touch actions is counterintuitive IMHO. The way we have it now - rectangle encircles, scribble touches - looks like the best overall balance to me.
On 2007-April-25 , at 17:00 , bulia byak wrote:
On 4/13/07, jiho <jo.irisson@...400...> wrote:
Proposed changes: => Ctrl+Alt+clic should display the first described behavior, even there is a group selected first (this would probably make things work the same for Shift+Ctrl+Alt+clic also). I think it is more consistent with the idea that Ctrl selects inside groups and does not contradict the idea that alt selects underneath the currently selected object
This would make it more complex. One of the ways to test a proposed change is to put yourself into the documentation writer's shoes and see if this change can be easily explained to the user. In this case, we'll have to repeat all existing explanations (already quite complex!) and then add, "except when the selected object is a group, in which case blah blah ..." It will likely terminally confuse a reader who somehow got as far as "except when".
On the other hand, what is the big benefit? You can get the same result by Ctrl+click and Ctrl+Alt+clicking in succession.
It is precisely what I was thinking about: IMHO current behavior can be difficult to understand and to explain. Ctrl+clic selects in group, Alt+clic selects under, therefore I expect Ctrl+Alt+Clic to always select under, entering groups when necessary. This is current behavior *except* when there is a group selected first. It is precisely this "except" that I think should be removed, for greater simplicity.
=> Shift+Drag should _toggle_ the selection of what is inside the selection rectangle and not just add. I cannot count the times when I would have had the use for this behavior in the past. In addition it is more consistent with Shift+clic toggle behavior.
Also disagree. I think the toggle behavior is only acceptable for a single object where you clearly see its current status. With bulk operations, it would be a disaster. I often do several shift+drags when I want to include many small objects in selection - and as a rule, my drags _overlap_ "just in case" so I don't miss anything. With yout proposal, overlapped areas will be deselected back - which will be a royal mess. What we need instead is a unconditional "subtract from selection" (not toggle!) mode for rubberband and touch selection. But we've absolutely run out of keyboard shortcuts for this :(
I agree it could get messy when trying to do what you describe but I had the opposite experience when trying to select many small objects, in particular when they are on another bigger one: I would like to be able to do a first broad selection and then crop out some parts of the selection from the borders by shift-dragging. But I agree that the best behavior would be to have a "subtract from selection" mode. See further down for keyboard shortcuts.
=> Ctrl+Drag and Shift+Ctrl+Drag behavior is strange when the selection is empty, I think it could (should?) do nothing
Why? It just works consistently the same as simple drag: selects the object where you started dragging and then moves it. That is, does "click and drag", not just "drag". The only logical difference is that with Ctrl it selects in groups (as you would expect).
I do not experience that: when the selection is empty, dragging creates a selection rectangle while Ctrl+dragging does nothing until it reaches an object. Furthermore when this object is a group, it does not selects inside the group and then moves the selected object as I would expect, instead it moves the whole group (with hor-ver constraints as expected though). I think it would be more logical and useful to use Ctrl+drag as a special selection mode dragging from an empty space i.e. creating a selection rectangle with special properties. I thought that it could be a rectangle with AI-like properties but it could also be the "subtract from selection" mode you just mentioned.
=> similarly Alt+Drag behavior is odd when the selection is not empty. IMHO, Alt+Drag should always draw a scribble selection path now. It is more useful.
Alt+dragging selection is useful too. Imagine you selected under some object completely covered by other objects and want to move it. I would probably use arrow keys, but not everyone is comfortable using them; many people prefer to drag by mouse. But you can't simply drag it - that will select the object on top of it. This is where Alt+drag comes to the rescue.
Besides, this is somewhat similar to how the regular drag works. It also does not always start rubberband, but only if you start dragging from an empty space; otherwise it moves objects. [...]
I see your point and I understand why Alt+drag on an object is useful. However the behavior I found odd is that you can alt+clic to select under, move the mouse and then alt drag above an empty space and it will still move your selected object. I do not see the use of this and this is not consistent with regular drag either. In regular drag when you drag from inside your selected object it moves it, when you drag from an empty space it creates a rubberband rectangle. I think the same behavior should apply to alt dragging now that alt +drag is assigned to a selection mode: alt+drag from inside a selected objects moves it, alt+drag from outside creates a touch selection path. Engraving work is a use case now when current behavior is particularly annoying: when switching from calligraphy tool (where the last drawn object is selected but no selection cues are displayed -and that's OK) to selector tool and trying to use touch selection, I always forget that my last drawn path is selected (cf. lack of selection cue) and move it instead of touch-selecting.
[...]
And in the end, long term improvement: => Create full "contact" and "encircle" selection modes: . In encircle mode rect selections behave as now, scribble selection paths are automatically closed and only objects inside are selected (i.e. lasso tool) . In contact mode, rect selection behave as in AI,
To be honest, I wrote the touch selection exactly so that I'm no longer bothered by requests to do the AI mode :) I really find it rather strange. A rectangle is, by its very nature, something encircling. Forcing it to do both encircling and touch actions is counterintuitive IMHO. The way we have it now - rectangle encircles, scribble touches - looks like the best overall balance to me.
I agree with you and AI behavior in this respect always annoyed me... but, well, there are many people used to it and I thought it may be worth the trouble. But in fact the real interest I had in this was for the encircling mode (i.e. lasso tool). I think it could really be useful and would probably solve the concerns we both have when selecting a bunch of small objects.
I tried to summarize my ideas in a table so that it is easier to get the "big picture". I represented current behavior, my previous proposal with contact and encircle selection mode and a draft for a subtract mode (but I have problems when shift and ctrl are used simultaneously because shift adds while ctrl subtract from selection). What do people think about it?
http://jo.irisson.free.fr/dropbox/inkscape/ inkscape_selection_behavior.pdf and the OO document in case someone wants to modify it: http://jo.irisson.free.fr/dropbox/inkscape/ inkscape_selection_behavior.odt
JiHO --- http://jo.irisson.free.fr/
participants (2)
-
bulia byak -
jiho