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.