Excuse me, does this issue about unique Node ID has final conclusion now?
I encountered the same issue about node resolution during the development of inkboard[1], too. Because inkboard should share nodes' information between two different inkscape document instances via network and need implementation about node resolution, too. So, I wonder whether we can cooperate on this issue together?
I'm not sure whether there is an existing way to solve this primarily, but I currently have some works[2] about this:
1. get node by id I implement a function "sp_repr_lookup_id" in utils.cpp[2] which will get the node by referred id. However, sometimes the document contain duplicated node with the same id, or some node without id. So the method do not provide an unique node resolution. I believe the GSoC project also has implementation about this, too.
2. use position sequences. This is the current method I use in inkboard. For example, the string "0-3-0" means that the 1st child of the 3rd child of the 1st child of the document root.
This implementation provide a pair functions "char* sp_repr_get_abs_pos_from_node( Node *node )" and "Node* sp_repr_get_node_from_abs_pos( char* abs_pos, Node *root )" to convert between nodes and position sequence strings. This works fine, but this require both sharing document should have the same xml repr. Or it will cause the nodes into chaos.
I guess this is also covered by XPath, but I'm currently not so familiar with XPath.
3. Inkscape has an existing component handling whiteboard via jabber too ( on the dir $INSCAPE/src/jabber_whiteboard ). In this component, it introduce KeyNodePair, and KeyNodeTable to maintain the mapping between the Nodes and ID strings. However, jabber_whiteboard currently not work on my laptop, so I have not enough data to evaluate this method. But I guess this may become a way to provide unique node ID string for external usage.
I apologized if I got something missing or duplicated. Please info me if there is something I can contribute or adjust, I would like to change and cooperate with :-)
sincerely, Mat.
[1]. http://code.google.com/p/inkboardng/ [2]. http://code.google.com/p/inkboardng/source/browse/trunk/inkdbus/utils.cpp
On Wed, Jul 15, 2009 at 3:56 AM, Ted Gould <ted@...11...> wrote:
On Fri, 2009-07-10 at 16:07 -0700, Jon A. Cruz wrote:
On Jul 10, 2009, at 11:19 AM, Glimmer Labs wrote:
This is exactly what I wanted to hear. Now does this behavior mandate
that every element have an id attribute. I think Inkscape does this by
default now. But it is not required by SVG and Jon Cruz has mentioned
many times in the past that he would like to change our behavior. Are we
talking id attributes or is there a unique id per element inside of
Inkscape?
I wasn't aware that that wasn't part of the SVG spec. All of my
knowledge about this sort of thing comes from opening up the XML
editor and changing values to see what they do. If the id attributes
get dropped I'll have to find another way to represent objects,
hopefully one that isn't too messy.
Yes, one main thing is that we need to kill id attributes except when absolutely required. Among other things, it really clutters the XML, and complicates things for technical users.
Though, we will always have a Unique ID for nodes. Whether that be a memory address or something generated. We just need to in the API documentation specify that it may not be the same as the ID attribute in the XML document. There is no reason to make it more complex as the scripting environment just needs a handle to track elements and that one is handy right now.
--Ted
Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel