On Sun, 2004-07-04 at 00:12, bulia byak wrote:
There's a problem. Right now I ctrl-click to select anything in a group, then I add some new object. I do NOT expect that object to be added into that group simply because something happens to be selected inside it. Your approach will result in a nasty surprise when later the user moves or deletes the group, and some unexpected outside object is affected.
No -- I oversimplified the rule a little bit. The exact rule would be this:
* if the selected object is a descendant of the current layer, nothing changes
* otherwise, the nearest sibling or ancestor of the current layer becomes the new current layer
So, simply selecting an object within a group using ctrl will not make that group the current layer.
Put another way, such implicit layer changes can only happen horizontally or up -- they'll never make a deeper group the current layer, avoiding these kind of surprises (which are obviously contrary to what users expect from layers and groups).
Now that I've had time to use the current layers code on real design work, there was one big logic oversight I made: children of sibling layers also need to be directly selectable.
Why sibling? Logically, objects in ANY non-locked visible layer must be selectable.
In the trivial case (only top-level groups/layers), there is no difference, and in the non-trival case (many levels of nesting), accidentally selecting objects in cousin layers can become problematic.
if you click something inside a group, it's selected (as in a layer!) instead of selecting the entire group.
Isn't that what the user would naturally expect to happen if that group were a sibling of the current layer?
In other cases (i.e. the group is a cousin or descendant of the current layer), they will of course expect "group-like" behavior.
Hence the sibling rule.
And that's another big problem with non-distinction of groups and layers: if you always treat them the same, groups lose their main reason for being -
I see it the other way around -- layers have no reason for being, except as a transient role for groups. Certainly I don't think they justify a separate object type.
So, unless I grossly misunderstand your approach, I really think we need to restore groupmode attribute and make layers and groups different kinds of objects.
It doesn't seem I'd adequately communicated the intended behavior.
If the above discussion didn't help, maybe if we went through some more specific use cases you're concerned about? I think you'd like it if you got to use it.
-mental