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