Difference between revisions of "Object Manager"
Latest revision as of 05:50, 13 July 2016
The Inkscape Object Manager
A hybrid of the XML Editor and Item Properties dialog.. mixed in with a bit of love.
- An expandable list of the groups and objects within your SVG. Previews of what is within that group is handy but not essential ( like in the XML editor: when groups are selected , the relative items on the canvas are selected )
- Groups can be expanded down to object level and each list item can be renamed.
- Each list item has a visibility and sensitive check button.
- Objects can be dragged from the list to the canvas. This will initiate a Use function to duplicate that group ( can we do this ? it would do wonders for economising file-size and graphics! )
- Should be able to. cloning objects does that now, and we are able to clone groups
Better for Semantics
Many Users will identify this manager as a type of 'Object Library' for their SVG documents.
The benefit here lies in the content. As users rename the objects they see in the manager they will be in-fact renaming the ID's in the XML.
This means the more semantic their documents, the more the user is rewarded with a logical 'object manager'.
Because it's as simple as double clicking your object in the manager to rename it, users will be not only encouraged too name objects for
Better for Users
When making objects sensitive and insensitive, users shouldn't have to go deep into the dark pits of the XML editor to make objects sensitive again. Same goes for objects with completely transparent fill and stroke.
When importing SVG from other applications - or even Inkscape-generated plain SVG - layers are lost. "Promote group to layer" would then be a great thing to do. Probably it'd be useful in other ways, too.
Clipping, masking and filter effects can be used on layers, too. Currently it's just hard to do, as it's not simple to select a layer.
The Gradient Manager
Currently when an object uses an existing gradient, inkscape will create a new lineargradientXXXX def id so that the x1y1 x2y2 coords can be changed. This def will then xlink:href to the existing gradient so that it can assume the colours and stops as the users.
The Gradient Manager provides a way to manage the names of both reference type gradient defs and also the gradient defs that contrain colour stop information. What also makes for a nice feature is you can re-use the reference gradients for exact-gradient positioning based off other objects :)
Things that happen as you interact with the gradient manager
- Draging and dropping objects above and below eachother changes their order in the xml
- Clicking on an object after it is selected allows the user to rename the id of that def
- Selecting a gradient after selecting an object applies that gradient
Gradient Dialog Design Ideas
And a screenshot of just the tool options bar for gradients:
If we want a solution that will scale beyond a few dozen gradients I'm convinced the task of creating or editing new gradients should be seperated out from the task of selecting and applying a gradient. Part of the reasion I created a set of gradients for OpenClipart.org was to have a sample set that made it clear to anyone redesigining the dialog that it would need to accomodate a whole lot of gradients. -- Alan
The way Xara does it: http://www.xara.com/products/xarax/flash/fill.htm