is there more to layers than just a menu??
I totally don't understand the concept right now. I though layers were supposed to be groups, basically.
David
On Sat, 2004-10-16 at 17:31, David Christian Berg wrote:
is there more to layers than just a menu??
I totally don't understand the concept right now. I though layers were supposed to be groups, basically.
Groups are the underlying mechanism, yes.
I've still got a lot of UI work left to do, but basically you can designate certain groups as "layers", in which case the objects within them will be directly selectable, and new objects can be drawn directly within them.
You can temporarily "promote" a group to a layer by right clicking on it and selecting "Edit within group" from the context menu.
We will eventually have a traditional-style layers dialog which shows these groups as well. We do already have a layer selector at the bottom of the window, but it isn't 100% functional yet either.
(I'm working on all this, so be patient)
-mental
(I'm working on all this, so be patient)
sure. the menu just got me confused, cause I couldn't figure out anything it was doing. But the edit group menu item is really cool already. Though, I don't think that single clicking an object that is not in the group should go back to root editing, because when you edit a group you might accidently click an object, that you didn't want to and - zooooomm- you're not editing the group anymore. maybe a doubleclick outside the group could leave the group again. On the other and I'm not sure I want to be able to leave a "layer" at all, after all, since there is no such thing as "root" once you call the groups layers. everything is in a group right from the beginning, since a canvas without a layer has to be a blank canvas.
So basically, with the introduction of layers it's about time to convert the old xml editor to a object treeview.
But I'm patient :)
David
On Sun, 2004-10-17 at 05:37, David Christian Berg wrote:
Though, I don't think that single clicking an object that is not in the group should go back to root editing, because when you edit a group you might accidently click an object, that you didn't want to and - zooooomm- you're not editing the group anymore. maybe a doubleclick outside the group could leave the group again.
I think that's something we need to work out in general for layers (of which groups are just a special case). 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.
On the other and I'm not sure I want to be able to leave a "layer" at all, after all, since there is no such thing as "root" once you call the groups layers. everything is in a group right from the beginning, since a canvas without a layer has to be a blank canvas.
In that instance there'd be no non-layers at the root level, so there'd be nothing to click on and kick you out.
One thing that will change is that currently the layer selector is disabled when you're at the root. That was just a temporary arrangement for 0.39 because of a combination of bugs and there not being any layers to select.
By the time we release 0.40 (or maybe 0.39.5, depending on how we split things), the default document template will start out with an initial layer rather than at the root level, so things should work a little more naturally then.
So basically, with the introduction of layers it's about time to convert the old xml editor to a object treeview.
The plan is to introduce a new dialog and keep (though rewrite) the XML editor. There are probably three main views of the tree that we want, ultimately:
1. layers - just the layers (in visual order) [selections in this one change the current layer]
2. objects - just the SVG objects (in visual order) [selections in this one change the current selection]
3. xml - all xml nodes (in XML order) [selections in this one change the current selection, if the XML node corresponds to an SVG object]
-mental
On So, 2004-10-17 at 17:28 -0400, MenTaLguY wrote:
On Sun, 2004-10-17 at 05:37, David Christian Berg wrote:
Though, I don't think that single clicking an object that is not in the group should go back to root editing, because when you edit a group you might accidently click an object, that you didn't want to and - zooooomm- you're not editing the group anymore. maybe a doubleclick outside the group could leave the group again.
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 ;)
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?? ;)
On the other and I'm not sure I want to be able to leave a "layer" at all, after all, since there is no such thing as "root" once you call the groups layers. everything is in a group right from the beginning, since a canvas without a layer has to be a blank canvas.
In that instance there'd be no non-layers at the root level, so there'd be nothing to click on and kick you out.
yeah, not a root level, but can't siblings kick me out? (You know, I have an older brother.... )
One thing that will change is that currently the layer selector is disabled when you're at the root. That was just a temporary arrangement for 0.39 because of a combination of bugs and there not being any layers to select.
By the time we release 0.40 (or maybe 0.39.5, depending on how we split things), the default document template will start out with an initial layer rather than at the root level, so things should work a little more naturally then.
Yup.
So basically, with the introduction of layers it's about time to convert the old xml editor to a object treeview.
The plan is to introduce a new dialog and keep (though rewrite) the XML editor. There are probably three main views of the tree that we want, ultimately:
layers - just the layers (in visual order) [selections in this one change the current layer]
objects - just the SVG objects (in visual order) [selections in this one change the current selection]
xml - all xml nodes (in XML order) [selections in this one change the current selection, if the XML node corresponds to an SVG object]
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.
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
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.
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.
I'd be all for the other powerful UI options, but I think even if it doesn't get any advancements, the xml editor would still be useful. As nice as it will be to have an object tree and a properties dialog, sometimes you just need to look at the raw xml to get a better understanding of where an issue may be hiding. Best example I can give is how there are WYSIWYG editors to make web sites, and they have every function possible built into a menu or dialog somewhere, but sometimes you need to just view the code (which to this day I prefer to handwrite websites in a text editor to control everything that goes in there). Could just be me... but I think it would still be useful for those of us that still take that gritty hands-on approach sometimes. Just my .02
-Josh
True. And don't forget the main reason:
--- Inkscape is an SVG Editor ---
People forget that sometimes. ;-)
There are many programs that provide general-purpose desktop publishing. But Inkscape (and SP) fill a need that very -few- programs provide: being a good editor for W3C-compliant SVG. XML is the whole reason for the thing. In fact, a more complete XML editor, even one that handled mixed namespaces, would be desireable. It would be rather useless for an SVG coder to not be able to view or modify the DOM tree.
Bob
Joshua A. Andler wrote:
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.
I'd be all for the other powerful UI options, but I think even if it doesn't get any advancements, the xml editor would still be useful. As nice as it will be to have an object tree and a properties dialog, sometimes you just need to look at the raw xml to get a better understanding of where an issue may be hiding. Best example I can give is how there are WYSIWYG editors to make web sites, and they have every function possible built into a menu or dialog somewhere, but sometimes you need to just view the code (which to this day I prefer to handwrite websites in a text editor to control everything that goes in there). Could just be me... but I think it would still be useful for those of us that still take that gritty hands-on approach sometimes. Just my .02
-Josh
On Mon, 18 Oct 2004, Bob Jamison wrote:
Date: Mon, 18 Oct 2004 11:23:48 -0500 From: Bob Jamison <rjamison@...357...> To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] layers
True. And don't forget the main reason:
--- Inkscape is an SVG Editor ---
People forget that sometimes. ;-)
There are many programs that provide general-purpose desktop publishing. But Inkscape (and SP) fill a need that very -few- programs provide: being a good editor for W3C-compliant SVG. XML is the whole reason for the thing. In fact, a more complete XML editor, even one that handled mixed namespaces, would be desireable. It would be rather useless for an SVG coder to not be able to view or modify the DOM tree.
Having used Jasc Webdraw which provides only text editor (with nice syntax colouring) I find the XML Editor rather cumbersome and in some cases more of a workaround for a missing or poor dialog (please dont ask me to be specific right now, I'll file those bug reports as I see 'em).
I would hope that the XML Editor could become more seperable in future so that there would be the option to use any generic text editor (vim, emacs, gedit, etc) or xml editor (conglomerate, mlview, xmlspy etc) instead of the built in XML Editor.
The XML Editor shouldn't ever be neccessary but it there should be no need to remove it entirely either. There will always be rare cases where it is useful to have finer grained control of the XML than it makes sense to expose in the user interface.
Sincerely
Alan Horkan
http://advogato.org/person/AlanHorkan/ Inkscape, Draw Freely http://inkscape.org Free SVG Clip Art http://OpenClipArt.org
On Mo, 2004-10-18 at 08:53 -0700, Joshua A. Andler wrote:
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.
I'd be all for the other powerful UI options, but I think even if it doesn't get any advancements, the xml editor would still be useful. As nice as it will be to have an object tree and a properties dialog, sometimes you just need to look at the raw xml to get a better understanding of where an issue may be hiding. Best example I can give is how there are WYSIWYG editors to make web sites, and they have every function possible built into a menu or dialog somewhere, but sometimes you need to just view the code (which to this day I prefer to handwrite websites in a text editor to control everything that goes in there). Could just be me... but I think it would still be useful for those of us that still take that gritty hands-on approach sometimes. Just my .02
-Josh
There is nothing wrong with _having_ the editor. I just don't want to _need_ it and would kinda hide it in an advance menu later on (also used for scripts).
David
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
On Tue, 19 Oct 2004 00:40:31 -0400, MenTaLguY <mental@...3...> wrote:
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 feel a bit confused :) I didn't managed to find anything about layers in SVG 1.1 spec. I can understand a "layer (group)" scheme, but "layer (group|nested layer)" is not very obvious to me. Is a nested layer the same as sublayer in Illy?
Alexandre
On Tue, 2004-10-19 at 03:37, Alexandre Prokoudine wrote:
I feel a bit confused :) I didn't managed to find anything about layers in SVG 1.1 spec. I can understand a "layer (group)" scheme, but "layer (group|nested layer)" is not very obvious to me. Is a nested layer the same as sublayer in Illy?
Could be. I haven't used Illustrator in a long time, so I don't remember the particulars too well.
The distinction between groups and layers is purely an Inkscape thing; in the underlying SVG they are both groups. Inkscape marks groups that are to act as layers with a special attribute.
The only major difference in behavior in Inkscape between the two is that layers directly expose the objects inside them, whereas a group is normally treated "as a whole". ("edit group" actually temporarily turns the group into a layer, on a per-window basis)
Layers also show up in the various places that list layers, but that's about it. A group being a layer doesn't change its rendering any.
-mental
participants (6)
-
Alan Horkan -
Alexandre Prokoudine -
Bob Jamison -
David Christian Berg -
Joshua A. Andler -
MenTaLguY