The idea is attractively simple, but I see some problems:
- layer visibility is an Inkscape-specific thing, separate from CSS
visibility of individual objects
That's problem #1. Remember that our SVG must render the same anywhere. If I hide a layer and save, I must not see that layer in Batik either. I don't see how you can achieve this, other than by manually adding SVG invisibility to all objects that are in an invisible layer (messy).
Also:
- I disagree that layers should not be related to z-order. A very useful operation (in a traditional vector editor) is re-z-ordering layers, which is not possible with your scheme - except if you select all objects in a layer and group them and move them up or down... which brings us back to the original scheme.
- The notion of current layer is possible (just add the name of the current layer to all newly created objects), but again this disregards z-order which may be very inconvenient. For example if I work in a layer which is on top of "background" layer but under the "shades" layer, I expect all new objects to be created in between these layers as well. In your scheme, they're still added on top of all objects, which makes the entire layer thing less than useful.
- The idea of an object belonging to more than one layer is cool, but the more I think of it the less I like it. I think it's just unclean and will give users lots of headaches (such as "Why hasn't this object disappeared when I hide its layer? Why do some objects in X disappear when I delete everything in Y?" etc) without significant advantages (or at least I don't see such advantages). When I want object X to be visible both with layer Y and with layer Z, I just put it in a third layer and name it accordingly and manipulate it as needed. I think it's saner that way.
Or am I missing something?
_________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI...
On Thu, 2004-06-10 at 01:24, bulia byak wrote:
That's problem #1. Remember that our SVG must render the same anywhere. If I hide a layer and save, I must not see that layer in Batik either. I don't see how you can achieve this, other than by manually adding SVG invisibility to all objects that are in an invisible layer (messy).
We could conceivably use CSS in some fashion (even if we don't support it yet ourselves). The UI for "layer" visibility I have in mind is similar to search, however ... not necessarily the kind of thing that would make sense to store persistently in the file.
Also:
- I disagree that layers should not be related to z-order. A very useful
operation (in a traditional vector editor) is re-z-ordering layers, which is not possible with your scheme - except if you select all objects in a layer and group them and move them up or down... which brings us back to the original scheme.
You're describing groups; this is something different.
- The notion of current layer is possible (just add the name of the current
layer to all newly created objects), but again this disregards z-order which may be very inconvenient. For example if I work in a layer which is on top of "background" layer but under the "shades" layer, I expect all new objects to be created in between these layers as well.
You're still describing groups.
- The idea of an object belonging to more than one layer is cool, but the
more I think of it the less I like it.
[...description of problems due to an expectation that layers are like groups...]
Or am I missing something?
I guess using the term "layers" sets up wrong expectations of behavior for people coming from Illustrator/graphic design backgrounds (because Illustrator calls its top-level groups "layers" and limits the functionality of child groups), so we will need to find a better term.
What I'm describing is fundamentally different (we will still have groups, so top-level groups will necessarily act like "Illustrator layers") -- think of my "layers" being like search keywords, where one can say "hide all objects not matching this set of keywords".
Actually there's nothing preventing the layer names from BEING keywords. Maybe we should run with that idea?
-mental
On Thu, 2004-06-10 at 02:14 -0400, MenTaLguY wrote:
- I disagree that layers should not be related to z-order. A very useful
operation (in a traditional vector editor) is re-z-ordering layers, which is not possible with your scheme - except if you select all objects in a layer and group them and move them up or down... which brings us back to the original scheme.
You're describing groups; this is something different.
That's besides the point. Bulia is spot on when he says any implementation should _not_ be Inkscape-specific. Any notion of layers should map directly into SVG and back so that no Inkscape-specific information has to be retained per-document.
- The notion of current layer is possible (just add the name of the current
layer to all newly created objects), but again this disregards z-order which may be very inconvenient. For example if I work in a layer which is on top of "background" layer but under the "shades" layer, I expect all new objects to be created in between these layers as well.
You're still describing groups.
If he's still describing groups then maybe Inkscape should drop the notion of layers and just work with groups.
I guess using the term "layers" sets up wrong expectations of behavior for people coming from Illustrator/graphic design backgrounds (because Illustrator calls its top-level groups "layers" and limits the functionality of child groups), so we will need to find a better term.
Illustrator also has it's own file format.
What I'm describing is fundamentally different (we will still have groups, so top-level groups will necessarily act like "Illustrator layers") -- think of my "layers" being like search keywords, where one can say "hide all objects not matching this set of keywords".
Actually there's nothing preventing the layer names from BEING keywords. Maybe we should run with that idea?
Anything that maps onto SVG and back seamlessly.
On Thu, 2004-06-10 at 05:19, Charles Goodwin wrote:
On Thu, 2004-06-10 at 02:14 -0400, MenTaLguY wrote: That's besides the point. Bulia is spot on when he says any implementation should _not_ be Inkscape-specific. Any notion of layers should map directly into SVG and back so that no Inkscape-specific information has to be retained per-document.
Our goal's always been to be SVG-compliant with respect to rendering; Inkscape files already contain a lot of information (in a separate namespace) that cannot map to pure SVG.
So long as we don't render SVGs in a non-compliant fashion as a result of that information being present, I don't see a problem.
Temporary visibility toggles for editing purposes aren't any worse than the "low quality", "non-antialiased" or "wireframe mode" rendering modes that are planned. When they're being used, the interface should make it clear that "what you see is not what you will get".
(and they shouldn't affect the rendering of output images, e.g. exported PNGs)
If he's still describing groups then maybe Inkscape should drop the notion of layers and just work with groups.
That's exactly what I'm advocating, actually, with the understanding that our interface ought to permit treating any group (not just the toplevel ones) in the same fashion as an Illustrator layer.
(as bulia pointed out, it can add some things, but we'll still need to do a lot of traditional "layers" things with groups)
Groups, especially as they're the underlying SVG primitive, oughtn't to be second-class citizens, of course.
-mental
participants (3)
-
bulia byak -
Charles Goodwin -
MenTaLguY