hide/show/lock objects from XML tree view (like Illustrator layers)

Bug #181578 reported by MenTaLguY on 2008-01-09
This bug affects 5 people
Affects Status Importance Assigned to Milestone

Bug Description

There should be a treeview (like the XML tree) which shows all objects and layers, and allows selecting, hiding, and locking them. In Illustrator, this was done by adding regular objects to the layers tree, but I personally think it messed up the UI for simple layer operations and made object operations more complicated than they needed to be. It seems like a more natural solution would be to add hiding/locking toggles to the XML tree, or something like it.

Tags: ui Edit Tag help

(The XML tree needs to be modernized and broken out of the layers dialog as a separate panel in this case)

Changed in inkscape:
importance: Undecided → Medium
status: New → Confirmed

(The XML tree needs to be modernized and broken out of the XML dialog as a separate panel in this case)

So, in terms of work items, that means roughly:

1. split the XML attributes and XML tree into separate dockable panels
2. add multiple selection to the XML tree
3. add show/hide/lock toggles to SPItems in the XML tree
4. add appropriate context menu items for tree items

Changed in inkscape:
assignee: nobody → mental
Martin Andersen (msandersen) wrote :

The XML editor is not meant as a permanently-visible palette referenced and used constantly while editing a drawing. It contains a lot of unrelated technical and non-visual information of the document which has nothing to do with the stacking order of objects. If it did, what would be the point of having 2 Layers palettes? Listing of layers, sublayers, groups, objects, paths, masks etc belong in the Layers Palette pure and simple. Only technical geeks would know to open the XML Editor to select or move objects which they look for in the Layers Palette.

You are thinking like a programmer, not an artist.

Declan Conlon (dec-cantab) wrote :

I'm going to have to agree with Martin Andersen.

Firstly a point about the audience of a program. While I am myself primarily a programmer I am occasionally asked to produce some graphics for my my company's products. However the task I'm trying achieve is produce an image. The relevancy of XML in this task is non-existent, the underlying representation of the graphic is of no value or interest for the task. In fact the only use case I can think of for ever exposing an XML tree representation of the image in production is for debugging purposes for the implementor of the software.

Secondly it is worth considering how this feature would be used. Having used some other image editing software one incredibly useful feature is the naming of objects in the document. Logically naming objects in a scene can be invaluable, particularly when collaboratively editing images. Another great use for an overview of objects is that of the object's history. Is the object a combination of a mask and a path? Is it a group of paths? All of this could be logically represented in a object/layer overview rather than the user knowing the underlying structure of the image itself. Also my initial feeling is that this would not be trivial to represent or even possible using a simple decomposition of the underlying XML document into a tree structure.

For me there are two unrelated bugs here: the issue of the XML tree view which could be improved to aid debugging of the software; the issue of presenting a user interface which helps people manage the elements of their document in a logical layer/document model. I'm not going to raise a new bug, though if asked I can do so with a full description of the feature in question, since this bug seems to be the most relevant bug given a quick search and I do not want to fragment the discussion of this feature. I hope this feature is given some more consideration.

What I have in mind is essentially turning what is currently XML editor into that.

Remember that this is SVG. There is basically a 1:1 correspondence between document objects and XML nodes, so the XML tree is already the "tree of all objects" which is desired. It just needs to show information which is more useful for artists and include lock and visibility toggles.

As far as "why have two layers dialogs"? We wouldn't. We'd have a layers dialog for selecting layers, and an objects dialog for selecting objects (including layers which also happen to be objects). I don't want to go down the road that Illustrator did where there are confusingly several different kinds of selection for the same items in the same dialog (current layer/current selection/etc...).

jazzynico (jazzynico) on 2009-09-09
tags: added: ui ui-selection-group-layer
Changed in inkscape:
importance: Medium → Wishlist
Giraldi Maggio (bedex78) wrote :

Another idea is to handle the lock feature the way Adobe Freehand does it.. that is, locked object can still be selected, but not edited.. so you can always unlock the object by selecting it.. This is a very handy feature that I missed..

Giraldi Maggio (bedex78) wrote :

..and objects can still snap to the locked objects to have them act as additional guides...

Rena Kunisaki (i-am-inuyasha) wrote :

It might be nice to just add a checkbox to the layers dialog to show objects as well. I'm debating with myself whether a separate dialog is more appropriate, but it might be bothersome to have the layers dialog *always* listing objects.

Cson (theceason) wrote :

we need to upgrade the layer/object control for inkscape
since we request some thing like this for several years

Kris (kris-degussem) wrote :

Comment 11 refers to Bug #171995

tags: removed: ui-selection-group-layer
Kazkas (kazkas) wrote :

For a similar available feature, please see:
http://wiki.inkscape.org/wiki/index.php/ObjectManager (XML Editor, XML Tree viewer)
https://inkscape.org/doc/advanced/tutorial-advanced.html (XML editor; shortcut=<Shift+Ctrl+X>)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers