In the small attached file I tried to order the objects top to bottom as: red line, the two gears (which are grouped), the polka dot rectangle. But I can't. I can only do these (all T->B):
1. Red line, rectangle, gears.
2. Gears, Red line, rectangle.
3. Gears, rectangle, Red line
4. rectangle, Red line, gears.

(This is easier to see if the red line is made wider than in the attachment.)

Or to put it another way, the only allowed orders are a core of [red line] next to [rectangle] with [gears] either above or below that pair.

Version 0.48 on windows XP SP3.

Bug? If not, why is it doing this?

mathog wrote:Bug? If not, why is it doing this?

Not really a bug, maybe a usability issue:

The group with the gears is outside the layer structure in the root level of the <svg> element. There, it is 'below' or 'above' the layer containing the other two objects, depending on the stack order. Moving the gears group back into the layer structure allows to freely change the stack order as needed (red line, the two gears, the polka dot rectangle).


To move an object which is in root back into a layer, select it, and use one of the layer commands ('Layer > Move selection to layer {above|below}'). Try which one works (the status line tells about success or failure) - it depends on the stack order as can be seen in the XML Editor.

Objects can be unintentionally placed into the [root] level, e.g.:

• some extensions which create new objects do this (ignoring the current layer)
• the focus issue discussed in a recent topic «What's this little text window for?» can cause the current layer to be set to root.

Once the current level is root, the next object(s) you create will be added in root too, unless you reset the current layer e.g. by clicking on another object (Inkscape always switches to the layer of the last selected object).

~suv wrote:The group with the gears is outside the layer structure in the [root] level of the <svg> element.

Got it. Thanks.

In what situation would one intentionally place a visible object in the root layer?

mathog wrote:In what situation would one intentionally place a visible object in the root layer?

For a shared background maybe? Also, when working with foreign or Plain SVG files, all objects will be on the root level.

Mostly I think this is a legacy issue from when Inkscape didn't know about layers (layers are not defined in the current SVG (1.1) specification - Inkscape implemented them as regular groups with a special tag which makes Inkscape interpret the group as layer).

Root layer has often caused me some problems (although I don't remember details) that I remember working around by adding one layer (layer one) in my default file along with my other customizations.

~suv wrote:

mathog wrote:Bug? If not, why is it doing this?

Not really a bug, maybe a usability issue:

I won't play semantics on this one. the simple fact is that inkscape at times does not behave the way users expect, and how other similar programs behave. And I am not referring to some of the ways one does things IN Inkscape, many of which are highly evolved and very usefully innovative.

But when a user creates objects and uses normal menu commands to place them above or below each other, and those functions don't work, or when objects suddenly appear to be layer-less, you can't lay that on "usability."

It is simply non-funcional, incorrect behavior. Users need to know that when they create objects on a layer, that the object will STAY on that layer, until the user moves it elsewhere. Same goes with same-layer operations of Move up, Move Down, Move to Top, Move to Bottom.


If these functions and layers don't work, what you have is a broken software application which will waste time by making editing and drawing headaches for the user.

Thank you

bender

linebender wrote:Users need to know that when they create objects on a layer, that the object will STAY on that layer, until the user moves it elsewhere.

It does stay on the level it was created (that''s also why it stays in root if created there - Inkscape doesn't move any object to root itself).

You won't argue with you about semantics - just keep in mind that in this forum, you do not address the developers, but other users trying to help. If you are not interested in how to work around this deficiency in the user interface… sorry to have wasted your and my time trying to explain. [edit] only saw your message in the other topic after having posted this reply - apologies for being too harsh here, and glad you were able to meet the deadline nevertheless. [/edit]

Related reports in the bug tracker:
Bug #166615 “hide (root) in layer list when there's a normal layer” (fixed)
Bug #166625 “root-level items trapped in root after first layer created” (Prematurely closed?)
Bug #488561 “Object still visible when all layers switched off.” (confirmed)

Bug #505225 “Layer text box popup” (makes root current layer if triggered)

(root) is not treated like a layer and consequently most of the available tools do strange things when an object is in there.
For instance (referring here to the first svg file I posted)

1. Layer -> Layers does not list (root), only layer1.
(Digressing slightly, that pop up dialog, or whatever it is called, should list all the objects in the layer, and they should be selectable from that list, but I don't see any way to make it so. Failing that, or additionally, there could be an
"Edit -> Select from list..." which would list all of the objects. This would be very useful because otherwise it can be a horrible PITA selecting objects that overlap each other. Also there are lock and view icons, but there should also be an icon that controls
whether or not objects in the layer can be selected. Sometimes you want to select objects in a layer based on their position with respect to objects in another layer, which is kind of hard now - too easy to end up selecting the wrong object.)

2. Just open the program with the svg file in question. If nothing is selected the "layer" selector at the bottom does not list (root),
giving no indication that it exists. However if the gears in (root) are selected first, then "layer" lists both (root) and layer1. Why should a layer exist only when an item in it is selected???

3. If one selects the gears (in (root)) and uses Layer -> move selection to layer above (or below, I forget which one works) the operation is not reversible. Attempting to move the gears BACK to root cannot be done this way, an error message "No more layers above" or "No more layers below" shows up instead.

Basically I think the interface needs a slight rework so that (root) is consistently included in the layer logic. It needs to be displayed
anywhere a layer is. If that isn't possible, then there should be no way for a user to put an object into (root) (except for objects which are not controllable by the user and that are never explicitly manipulated). In every situation where objects now end up in (root) they should land in (current layer), which at program startup would be layer1, even if there layer1 was empty. Somewhere in this thread it was mentioned that some SVG files open with everything in (root). That doesn't make sense to me, that sort of file should open with everything in layer1 instead.

mathog wrote:Somewhere in this thread it was mentioned that some SVG files open with everything in (root).

The current SVG specification doesn't define layers as a way to structure a document. Inkscape uses private attributes to implement them (they are normal groups with an 'inkscape:groupmode="layer"' attribute). Standardized layers are high on the list of ideas where Inkscape could (and should) influence the future of SVG.

mathog wrote:That doesn't make sense to me, that sort of file should open with everything in layer1 instead.

I doubt that Inkscape should modify the structure of valid SVG documents on load. SVG is not proprietary to Inkscape, it's an open standard and used widely by other applications and on the web. Authors might have reasons not to use inkscape layers.

It seems difficult to unite opposing concepts under the same UI (root is not a layer - should it still be listed in the Layers dialog, or only in the indicator of the current drawing level of the status bar? etc). Possibly the uncertainty if and when layers will be part of the SVG spec is holding back development efforts.

~suv wrote:It seems difficult to unite opposing concepts under the same UI (root is not a layer - should it still be listed in the Layers dialog, or only in the indicator of the current drawing level of the status bar? etc). Possibly the uncertainty if and when layers will be part of the SVG spec is holding back development efforts.

The description of SVG rendering in 3.3 here

http://www.w3.org/TR/SVG/render.html

sounds as if all the SVG objects are, in effect, numbered 1->N, and are painted in that order. (With complications when elements are grouped.) By that definition "layers" could logically consist of numeric ranges like {1},{2,6},{7,10},{11,N}. The default on opening a standard document would of course be one layer with all objects, being the range {1,N}, called layer1 or whatever in inkscape, and (root) problem solved. (He says, sweeping many issues under the rug.) Layer split is one range becomes two and layer merge is two adjacent ranges become one. Easy. Adding a layer above would insert a null object at N+1, which could be removed if any real objects ever inhabit that layer. It is obvious in this simple model what object creation, deletions, and movements up and down do (or do not do) to the layer ranges. There is a lot of object renumbering, which might cause performance problems with 100K or more objects, but shouldn't be an issue with less than that. One could even store layer boundaries by inserting nonpainting named objects at the appropriate positions in the object sequence.

Apparently that isn't the model Inkscape uses for layers now though, because if it was we wouldn't be having this conversation.

mathog wrote:Apparently that isn't the model Inkscape uses for layers now though, because if it was we wouldn't be having this conversation.

Huch? Are you saying Inkscape doesn't follow the SVG 1.1 specification to render SVG files?

Objects are not rendered by number (ID) - only the sequence in which they are stored in the source file is relevant (the implicit drawing order): those that are first in the file are painted first, and the following ones are painted on top of them, making the first object in the file the bottom-most in z-order. Inkscape adheres to this concept.

Did you take a closer look how Inkscape implements layers? Again, SVG 1.1 doesn't have a concept of layers - it knows groups to structure the content, which is what Inkscape uses as layers (a layer in Inkscape is a group with a special, private attribute). Have a look at the XML Editor, drag an object into the root level and see how you can move it before, between or after the existing top-level layer groups. Note that what you see in the original source and in the XML Editor is reverted in relation to top|bottom compared to what you see in the 'Layers' dialog: objects/groups/layers that come last in the SVG source, are painted on top on-canvas (likewise are the last layer groups those at the top in the 'Layers' dialog).
In sort-of-pseudo-code:

This discussion is beyond the scope of the 'Help with using Inkscape' board - IMHO it should continue in one of 'Inkscape Ideas', 'Discuss Software Issues' or 'SVG / XML Code'. My motivation in answering the questions about objects getting lost or caught in root in this board is to help to work around the (known) GUI deficiencies and describe how to handle (and possibly avoid) these exceptions. I'm not an interface designer nor a developer and don't have the skills to seriously discuss or develop a blueprint+mockup for this recurring topic (enhanced layer + group + object browser|management).

~suv wrote:

mathog wrote:Apparently that isn't the model Inkscape uses for layers now though, because if it was we wouldn't be having this conversation.

Huch? Are you saying Inkscape doesn't follow the SVG 1.1 specification to render SVG files?

Objects are not rendered by number (ID) - only the sequence in which they are stored in the source file is relevant (the implicit drawing order): those that are first in the file are painted first, and the following ones are painted on top of them, making the first object in the file the bottom-most in z-order. Inkscape adheres to this concept.

That's what I meant.

~suv wrote:Did you take a closer look how Inkscape implements layers? Again, SVG 1.1 doesn't have a concept of layers - it knows groups to structure the content, which is what Inkscape uses as layers (a layer in Inkscape is a group with a special, private attribute). Have a look at the XML Editor, drag an object into the root level and see how you can move it before, between or after the existing top-level layer groups. Note that what you see in the original source and in the XML Editor is reverted in relation to top|bottom compared to what you see in the 'Layers' dialog: objects/groups/layers that come last in the SVG source, are painted on top on-canvas (likewise are the last layer groups those at the top in the 'Layers' dialog).
In sort-of-pseudo-code:

Code: Select all

    <svg name="InkscapeTemplate">
    <defs>
    -- <layer 1>
           <object1>
           <object2>
           <object3>
    -- <layer 2>
           <object1>
    -- <layer 3>
           <object1>
           <object2>
    </svg>

    <svg name="ObjectsInRoot">
    <defs>
    -- <object 1>
    -- <object 2>
    -- <layer 1>
           <object1>
           <object2>
           <object3>
    -- <layer 2>
           <object1>
    -- <object 3>
    -- <layer 3>
           <object1>
           <object2>
    </svg>

This discussion is beyond the scope of the 'Help with using Inkscape' board - IMHO it should continue in one of 'Inkscape Ideas', 'Discuss Software Issues' or 'SVG / XML Code'. My motivation in answering the questions about objects getting lost or caught in root in this board is to help to work around the (known) GUI deficiencies and describe how to handle (and possibly avoid) these exceptions. I'm not an interface designer nor a developer and don't have the skills to seriously discuss or develop a blueprint+mockup for this recurring topic (enhanced layer + group + object browser|management).

Right, I understood that it uses groups. However, the attachments indicate an issue with groups I alluded to in my last post. In renderorder the objects are interleaved along Z with the order shown by the numbers, there is only one layer. This is easy to verify by sliding the pieces around to see what covers what. Now, select all 3 L shaped pieces on the left (not the numbers, just the shapes) and group them. The order changes, the full interleaving is lost. Once they are grouped the order within the group is unchanged, but the group as a whole draws as a single unit, so it falls in effect on just one of the previous draw levels. Where if falls is a little arbitrary, it seems to pick the topmost object for the position. Move the group up or down and there is no position where it interleaves again. Ungroup, but leave the 3 pieces on the left selected so they can be moved together, and move up/down and it is possible to re-interleave. This is I think what the SVG intends, that the position of the group object overrides that of the position of the members of the group. Here it does not destroy the original order (it is unclear to me what SVG says about that point). Now look at renderorder2. In that one the top 3 pieces have been moved into a second layer, layer2, but the draw order is the same. Again, group the 3 on the left and they "flatten" to a single layer relative to the remaining pieces, and this time they are placed in layer2. Do not move them. Now, ungroup and they are all still assigned to layer2, so it isn't possible to interleave the pieces again (short of moving the bottom two on the left back to layer1).

My point being that the Inkscape layers change the render order of the pieces following a group/ungroup operation. I'm not sure that that is SVG compliant. It might be, I just don't know. In the second case, given that SVG does not have a layers concept, shouldn't the ungrouped pieces have reverted to their original positions, even though those were in a layer different from the group?

I will now (re)open this discussion to the forum you suggested.