On 2007-April-25 , at 17:00 , bulia byak wrote:
> On 4/13/07, jiho <jo.irisson@...> 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
>> => 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
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?
and the OO document in case someone wants to modify it: