On Sun, 2004-10-17 at 18:15, David Christian Berg wrote:
I think that's something we need to work out in general for layers (of which groups are just a special case).
now this makes me smile: groups are a special case of layers... I always thought it was the other way around ;)
Whichever. Your way is probably a better description of it.
In most apps, clicking on an object in a different layer will switch layers, but for us, one layer can be the parent of another, possibly requiring different behavior...
I guess part of the question might be whether direct selection of objects which are "uncles" or "cousins" of the current layer should be possible, whether it should be done with a special click sequence/key combination, and under what conditions that should cause a layer switch.
well, iirc this is true for indesign (I hardly ever use layers in corel), but when it comes to bitmap editing (gimp) you can only work on the current layer... of course there are no objects to select... maybe shift+click would be a possibility to move to _any_ other layer. This includes siblings, parents, uncles, cousins, grandparents... parents in law?? ;)
We might want to think about repurposing ctrl+click slightly, actually. I'll need to think about it some more.
now, I wonder if from the usability point of view we maybe want to call the top level groups layers, but any other still groups. I mean otherwise you'd have to go for "make layer" instead of "group" and "split layer" instead of "ungroup". Doesn't feel right to me.
Well, you can have nested layers (i.e. inkscape:groupmode="layer"); it's actually a useful thing to have. That's different from layers containing groups (inkscape:groupmode="group").
I have not figured out the best UI for creating a nested layer, though. That may have to wait for the proper layers dialog.
also: what do you mean by main views? a tree view is a tree view... something like
[+] defs [-] canvas [+] layer1 [-] layer2 rectangle1 [-] group1 image12 [+] group2 [+] group3 object14 [+] layer3
Yes, but there are some subtle differences. For an object tree, I'd want to put the objects in the reverse order (decreasing z-order), as that's the traditional ordering for object trees/lists in graphics apps.
Only the XML tree would be displayed sorted in document order.
and why keep the xml editor? There should be a UI for everything the xml editor can do, so the object tree lets you select any object and a properties dialog lets you set the stuff that you otherwise would set int he editor.. not sure if just one dialog though.
The reason to keep the XML editor is to ... edit XML.
We can't provide a specialized UI for everything possible, because one of our core goals is to support SVG files containing arbitrary embedded XML.
Commonly-used XML grammars (like RDF) should and will eventually get their own UI (like our metadata dialog), but I firmly believe any XML in the file should be editable without having to wait for someone to implement a specialized UI. We've gone through great architectural pains to make sure that can happen.
For what it's worth, my plan is indeed to split the current XML editor in two, (see a few months back in the list archives where I go into more detail about this). The tree part would share a dialog with the other tree views (layer and object), and the attributes part would go into a page of a properties dialog.
I'd like, eventually, to also have a straight text editor as well (with some syntax constraints/highlighting for XML), but that is a major project in its own right. I'd probably rather reuse one of the existing editors somehow for that (but for that we need to expose a live DOM to external apps somehow; saving XML to a temporary file and then reading it back won't cut it).
Please remember Inkscape's audience includes people who are interested in the XML features of SVG as well as its graphical ones.
-mental