Just a quick note that I've been polishing the layers feature and even without the layers dialog it's becoming rather usable. So basic layers (of a sort) might actually make it in for this release.
Here are some of the relevent changes:
* I've retired the inkscape:groupmode attribute as it has served its purpose
* You get Sodipodi-style "enter group"/"leave group" commands on the context (right click) menu which can be used to switch to using a group as a layer, or switch back to that group's parent
* when a group is in this "layer" mode, the drawing tools create shapes within it and you can drag and select its objects directly
Here are the items that are still needed:
* The "group mode" setting needs to be per-NRArena key, and persist across hide/show cycles (currently, the change in event handling behavior is global, even though layer activation is per-SPDesktop)
* Some sort of visual indicator of the current layer would be nice. I have provided an SPDesktop (SigC++) signal for this purpose, which can be connected to via SPDesktop::connectCurrentLayerChanged()
* should e.g. "Select All" etc be influenced by the current group?
-mental
- The "group mode" setting needs to be per-NRArena key, and persist
across hide/show cycles (currently, the change in event handling behavior is global, even though layer activation is per-SPDesktop)
But will it persist across sessions? I don't quite understand your reasons for removing groupmode, I think layers must remain layers when you save the document. On the other hand, making it able to differ across desktops does not seem terribly useful to me.
- Some sort of visual indicator of the current layer would be nice. I
have provided an SPDesktop (SigC++) signal for this purpose, which can be connected to via SPDesktop::connectCurrentLayerChanged()
I think it's important enough to separate a section of the statusbar to show the id of the current layer.
- should e.g. "Select All" etc be influenced by the current group?
No. All non-locked objects are selected. If you want to exclude a layer from selection, lock it.
On Sat, 2004-07-03 at 01:14, bulia byak wrote:
- The "group mode" setting needs to be per-NRArena key, and persist
across hide/show cycles (currently, the change in event handling behavior is global, even though layer activation is per-SPDesktop)
But will it persist across sessions? I don't quite understand your reasons for removing groupmode, I think layers must remain layers when you save the document.
I sort of changed my mind about layers being a special mode.
The ultimate plan now is to make groups behave like either groups or layers depending on whether the user is currently performing group-things or layer-things with them. Ideally, this would be entirely natural, so there would be no obvious "mode-change" to the user.
So, inkscape:layermode was a temporary hack to selectively confer layer-like behavior on groups via the XML editor without writing extra UI code, so I could get some artwork done. I'm repurposing some of its implementation now.
The current "enter group"/"leave group" facility is of course far from ideal (among other things because you have to already have something in the group before you can click on it and get the menu), but once I implement the layers dialog in 0.40 it should be pretty natural.
The initial/default appearance of the layers dialog would show only the top-level objects, ordered in visual z-order (reverse of XML order). In a document structured in a traditional layered fashion, these top-level objects would be groups, and in this setting look precisely like layers to the user.
Clicking in the rightmost column of a particular layer's (group's) row would put a little pencil icon (or similar) next to it, making it the current layer for editing (performing the equivalent of "enter group").
IOW, this (abridged) document:
<svg> <g id="layer-1" sodipodi:insensitive="1"><circle/></g> <g id="layer-2"><rect/><rect/></g> <rect id="blah"/> <g id="new-layer"/> </svg>
...would appear in the layers dialog something like this (assuming #layer-2 were the current layer):
---------------------------- [@] [ ] #new-layer [ ] ---------------------------- [@] [ ] #blah ----------------------------
[@] [ ] #layer-2 [/]
----------------------------
[@] [^] #layer-1 [ ]
----------------------------
[@] = eye icon - visible [^] = lock icon - locked [/] = pencil icon - current layer
= tree expander (to see children)
[ note omission of pencil "slot" on non-groups ]
We might have some thumbnails or something in there too. I expect there would also be a "new layer" button, which would just create an empty top-level group (which, for the user, is essentially a layer), and whatever other layer manipulation buttons/commands seem appropriate.
Normally I expect users are either going to put all their objects at the top level and not group much, or they will put everything in top-level groups (i.e. layers), so a mixed document like this example will be uncommon.
However, this example should give you an idea of what a range of cases would look like.
On the other hand, making it able to differ across desktops does not seem terribly useful to me.
Permitting each desktop to have its own "current layer" will be necessary when I implement the ability to select a different element as the "root" for a particular editing view. That feature will be crucial for editing SVG islands in non-SVG XML documents, and perhaps also handy for e.g. directly editing objects/groups in <defs>.
-mental
MenTaLguY abbozzò:
[...]
However, this example should give you an idea of what a range of cases would look like.
I like very much this proposal. It feels like the most natural way to get layers using groups without adding complexity but making groups more powerful.
Great work!
On Sat, 2004-07-03 at 06:16, Emanuele Aina wrote:
I like very much this proposal. It feels like the most natural way to get layers using groups without adding complexity but making groups more powerful.
Great work!
Thanks~
Credit where credit is due, though. My idea is just a synthesis of existing proposals made by Lauris Kaplinski, Brisgeek, and bulia.
-mental
The initial/default appearance of the layers dialog would show only the top-level objects, ordered in visual z-order (reverse of XML order). In a document structured in a traditional layered fashion, these top-level objects would be groups, and in this setting look precisely like layers to the user.
This will only work if we will always create a new document with a top-level <g> that is made current at once. Otherwise, as well as with all old documents, the dialog will be flooded by top-level groups which were meant to be groups but are now presented as layers. Do you think this is a problem?
Clicking in the rightmost column of a particular layer's (group's) row would put a little pencil icon (or similar) next to it, making it the current layer for editing (performing the equivalent of "enter group").
Why not just highlight the entire line (no pencil) when clicking on the layer name (no rightmost column)? In any case, having highlight on one layer but pencil on another is going to be very confusing.
[ note omission of pencil "slot" on non-groups ]
Why do we need to show non-groups at all? Only to make it easy to lock/unlock them? I think they will be increasingly annoying for those who just need a layers dialog, and will make the dialog almost unusable for complex documents. I think the displaying of non-layers must be optional and off by default (but with an easily accessible checkbox right on the dialog).
On the other hand, showing non-groups at all is going to be confusing if we use highlight as the means to indicate current layer. I think a good way to resolve this would be:
- on clicking a non-group, make its parent layer current and highlight it to indicate that
- the object itself that you clicked on is also highlighted but using a different (lighter) color
We might have some thumbnails or something in there too. I expect there would also be a "new layer" button, which would just create an empty top-level group (which, for the user, is essentially a layer), and whatever other layer manipulation buttons/commands seem appropriate.
Not top-level, but a sibling of the current layer. The two buttons (new and delete) are the necessary minimum, plus the ability to rearrange layers by dragging.
We'll also need menu commands to "move selection one layer up/down" which would work without having to open the dialog. If there's no layer above/below, I think it's appropriate for these commands to display a messagebox telling the user that and offering to create a new layer for the selection contents. If the layer exists, the command does what it is asked to do silently, and makes the layer to which it moved stuff current. Selecting an object makes its layer current too. You can have objects from different layers selected, but some commands will not be available then (there are already checks and warnings for that in most commands). Finally right-clicking on the current layer name in the statusbar must display a menu with "lock/unlock" and "hide/show" commands (for the current layer) as well as the list of sibling layers of the current. And when you attempt to create or paste or import something into a locked or invisible layer, Inkscape must display a warning.
So looks like quite a bunch of UI and logic work is needed, beyond the layers dialog.
Normally I expect users are either going to put all their objects at the top level and not group much, or they will put everything in top-level groups (i.e. layers), so a mixed document like this example will be uncommon.
As said above, we should encourage proper layering by starting a new document with an empty layer.
Permitting each desktop to have its own "current layer" will be necessary when I implement the ability to select a different element as the "root" for a particular editing view.
Sure, different desktops may each have a different current layer.
One more thing: I have already written about it, just wanted to reiterate: for visibility, we need to use the CSS property, not some non-standard attribute as does Sodipodi.
First of all, this proposal for layers is awesome!
Four things:
1.) Agree about the 1st layer switch which should be on by default, but for advanced users (or anyone) they can turn this off.
2.) Allow the non-group objects to have other items dragged onto it to convert it to a group (good functionality from adobe illustrator).
3.) Also, double click or control click of the layer or entry on the layer palette auto-selects the associated object(s).
4.) Don't forget merge layers as another button on the GUI.
ROCK! Jon
On Sat, 2004-07-03 at 19:44, bulia byak wrote:
The initial/default appearance of the layers dialog would show only the top-level objects, ordered in visual z-order (reverse of XML order). In a document structured in a traditional layered fashion, these top-level objects would be groups, and in this setting look precisely like layers to the user.
This will only work if we will always create a new document with a top-level <g> that is made current at once. Otherwise, as well as with all old documents, the dialog will be flooded by top-level groups which were meant to be groups but are now presented as layers. Do you think this is a problem?
Clicking in the rightmost column of a particular layer's (group's) row would put a little pencil icon (or similar) next to it, making it the current layer for editing (performing the equivalent of "enter group").
Why not just highlight the entire line (no pencil) when clicking on the layer name (no rightmost column)? In any case, having highlight on one layer but pencil on another is going to be very confusing.
[ note omission of pencil "slot" on non-groups ]
Why do we need to show non-groups at all? Only to make it easy to lock/unlock them? I think they will be increasingly annoying for those who just need a layers dialog, and will make the dialog almost unusable for complex documents. I think the displaying of non-layers must be optional and off by default (but with an easily accessible checkbox right on the dialog).
On the other hand, showing non-groups at all is going to be confusing if we use highlight as the means to indicate current layer. I think a good way to resolve this would be:
- on clicking a non-group, make its parent layer current and highlight
it to indicate that
- the object itself that you clicked on is also highlighted but using
a different (lighter) color
We might have some thumbnails or something in there too. I expect there would also be a "new layer" button, which would just create an empty top-level group (which, for the user, is essentially a layer), and whatever other layer manipulation buttons/commands seem appropriate.
Not top-level, but a sibling of the current layer. The two buttons (new and delete) are the necessary minimum, plus the ability to rearrange layers by dragging.
We'll also need menu commands to "move selection one layer up/down" which would work without having to open the dialog. If there's no layer above/below, I think it's appropriate for these commands to display a messagebox telling the user that and offering to create a new layer for the selection contents. If the layer exists, the command does what it is asked to do silently, and makes the layer to which it moved stuff current. Selecting an object makes its layer current too. You can have objects from different layers selected, but some commands will not be available then (there are already checks and warnings for that in most commands). Finally right-clicking on the current layer name in the statusbar must display a menu with "lock/unlock" and "hide/show" commands (for the current layer) as well as the list of sibling layers of the current. And when you attempt to create or paste or import something into a locked or invisible layer, Inkscape must display a warning.
So looks like quite a bunch of UI and logic work is needed, beyond the layers dialog.
Normally I expect users are either going to put all their objects at the top level and not group much, or they will put everything in top-level groups (i.e. layers), so a mixed document like this example will be uncommon.
As said above, we should encourage proper layering by starting a new document with an empty layer.
Permitting each desktop to have its own "current layer" will be necessary when I implement the ability to select a different element as the "root" for a particular editing view.
Sure, different desktops may each have a different current layer.
One more thing: I have already written about it, just wanted to reiterate: for visibility, we need to use the CSS property, not some non-standard attribute as does Sodipodi.
This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, 2004-07-03 at 22:44, bulia byak wrote:
This will only work if we will always create a new document with a top-level <g> that is made current at once.
That's the plan.
I think the general rule on loading should probably be to make the first group the current layer if there are only groups at the top level (i.e. the document author has used them for layer-like structure). Under that rule such a document template would do what you expect.
Otherwise, we start out with editing in the root element, as we currently do (since the original document author must not have been thinking in layer-structure).
Otherwise, as well as with all old documents, the dialog will be flooded by top-level groups which were meant to be groups but are now presented as layers. Do you think this is a problem?
Not particularly, given the above rule. If they are putting nothing but groups at the top level, they probably wanted layers anyway. In the rare case where they do not it is easy to back out to drawing in the root element.
We must of course have a clear visual indication of which layer (or the root) is current, though.
I think the displaying of non-layers must be optional and off by default (but with an easily accessible checkbox right on the dialog).
We'll see. I personally think showing everything at the top level by default is better. I think you're right that for large/complex documents some sort of filtering facility (not only for filtering groups, though) would be helpful.
On the other hand, showing non-groups at all is going to be confusing if we use highlight as the means to indicate current layer. I think a good way to resolve this would be:
- on clicking a non-group, make its parent layer current and highlight
it to indicate that
The general rule would be that selecting an item (through whatever means) that was not on the current layer would switch to the layer containing that item [in multiple selections, the most recently selected object wins]. I think that's the generally expected behavior for layers.
- the object itself that you clicked on is also highlighted but using
a different (lighter) color
That's basically what I'm "faking" with the pencil icon. Like most standard list widgets, the standard Gtk widget only gives us one type of highlight, so pencil-icon-for-current-layer has become a common UI idiom in graphics tools.
Why not just highlight the entire line (no pencil) when clicking on the layer name (no rightmost column)? In any case, having highlight on one layer but pencil on another is going to be very confusing.
I'm willing to change my mind depending on how it works in practice, but I don't want to start by making custom widgets that don't work with arbitrary Gtk themes (because Gtk only has one fundamental highlight color).
[ regarding "new layer" ]
Not top-level, but a sibling of the current layer. The two buttons (new and delete) are the necessary minimum, plus the ability to rearrange layers by dragging.
Ah, you're right.
We'll also need menu commands to "move selection one layer up/down" which would work without having to open the dialog. If there's no layer above/below, I think it's appropriate for these commands to display a messagebox telling the user that and offering to create a new layer for the selection contents.
Hmm, I guess that would be useful, although I'm not sure I'd use it much. You can implement that one. ^_-
If the layer exists, the command does what it is asked to do silently, and makes the layer to which it moved stuff current. Selecting an object makes its layer current too.
Ok, yes. See earlier.
You can have objects from different layers selected, but some commands will not be available then (there are already checks and warnings for that in most commands).
Right -- it's not a problem specific to layers, just a general problem of multiple selected objects which are not siblings.
Finally right-clicking on the current layer name in the statusbar must display a menu with "lock/unlock" and "hide/show" commands (for the current layer) as well as the list of sibling layers of the current.
Hmm, I was thinking ancestors, but siblings are more useful. Maybe a hybrid approach of putting an indented menu like:
#svg324 #g430 #g200 * #g403 #g404
So all ancestors and siblings of the current layer are shown, and a bullet indicates the current layer.
[ this particular example shows a second-level group being used as a layer ]
And when you attempt to create or paste or import something into a locked or invisible layer, Inkscape must display a warning.
Yes. Actually, in the case of a locked layer, such actions should ideally be completely disabled and their corresponding buttons grayed out [ in general we need to do some architecture work so impossible actions are greyed out ].
So looks like quite a bunch of UI and logic work is needed, beyond the layers dialog.
I think the layers dialog is enough to start with (actually in practice the minimal layers support I'm putting in for 0.39 seems enough to be usable, if not ideal), but of course we can keep refining it.
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. I'm currently implementing that, along with the object-selection-changes-current-layer rule discussed above.
As said above, we should encourage proper layering by starting a new document with an empty layer.
Seconded.
Sure, different desktops may each have a different current layer.
That's all I was suggesting.
One more thing: I have already written about it, just wanted to reiterate: for visibility, we need to use the CSS property, not some non-standard attribute as does Sodipodi.
Agreed.
-mental
I think the general rule on loading should probably be to make the first group the current layer if there are only groups at the top level (i.e. the document author has used them for layer-like structure). Under that rule such a document template would do what you expect.
OK, that sounds right.
The general rule would be that selecting an item (through whatever means) that was not on the current layer would switch to the layer containing that item [in multiple selections, the most recently selected object wins]. I think that's the generally expected behavior for layers.
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.
What do you think? Keeping groupmode attr would have prevented this, and in general I don't see much reason for removing it. I think keeping a persistent distinction between groups and layers (the layers still being able to nest into each other) would be cleaner and more intuitive.
Finally right-clicking on the current layer name in the statusbar must display a menu with "lock/unlock" and "hide/show" commands (for the current layer) as well as the list of sibling layers of the current.
Hmm, I was thinking ancestors, but siblings are more useful. Maybe a hybrid approach of putting an indented menu like:
#svg324 #g430 #g200
#g403 #g404So all ancestors and siblings of the current layer are shown, and a bullet indicates the current layer.
Agreed.
And when you attempt to create or paste or import something into a locked or invisible layer, Inkscape must display a warning.
Yes. Actually, in the case of a locked layer, such actions should ideally be completely disabled and their corresponding buttons grayed out [ in general we need to do some architecture work so impossible actions are greyed out ].
Yes.
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. 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 - if you click something inside a group, it's selected (as in a layer!) instead of selecting the entire group. 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.
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
participants (4)
-
bulia byak -
Emanuele Aina -
Jon Phillips -
MenTaLguY