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/