I've looked into this a little bit more now when the GUI is more or less complete (Gtkmm 2 for now). In the Document Properties I've added the "Metadata and License" tab. Name can be discussed and I have also left the "Metadata" and "License" tab as is for now during development, they will be removed later on. Code can be found at lp:~christoffer-holmstedt/inkscape/improved-copy-paste-with-metadata

### The RDF refactoring
So after thinking about RDF within Inkscape for a while I like your idea Markus. This is my proposal...

RDFNode : SPObject;
- Class that can be instantiated as rdf:RDF, rdf:Bag, rdf:Seq or similiar nodes.

RDFTriple : SPObject;
- One object for each triple (value).

The difference between RDFNodes and RDFTriples would be that RDFTriples include values and RDFNodes contain building blocks to build the rdf structure. Any comments about this are appreciated.

### Questions
1) If I make changes directly in the XML editor some values affect the image as soon as I set the value. Though if I change any Metadata value in current trunk it will not change the GUI. How do properly make this work in this new version? Should the GUI somehow "listen" for updates to the object tree or xml tree?

2) I should try to work with the typed object tree as much as possible and not directly to the xml tree, should changes to the xml tree then go through each object in the typed object tree?

3) Should I keep the "sp" prefix for now as long as we keep using the SPObject, so it should rather be SPRdfNode and SPRdfTriple?

--
Christoffer Holmstedt


2013/7/29 Christoffer Holmstedt <christoffer.holmstedt@...400...>
Thank you very much. I will look into this during the upcoming week.

--
Christoffer Holmstedt


2013/7/27 Markus Engel <p637777@...1081...>
Hi,
I generated the documentation for the object tree and picked out the relevant parts for you:
https://dl.dropboxusercontent.com/u/37427492/sp-object.pdf
https://dl.dropboxusercontent.com/u/37427492/sp-metadata1.pdf
https://dl.dropboxusercontent.com/u/37427492/sp-metadata2.pdf
 
Note that this is not how it is currently implemented in trunk, but in my own branch instead. This shouldn’t matter for understanding, though, I just converted the tree to “real” c++ classes.
SPObject is the base class for all tree nodes. As you can see in the first pdf, every svg element has got one counterpart of the right class in the object tree. Whenever a change is made to an xml node, it informs the tree node belonging to him by calling for example onUpdate(). The tree node then updates its internal state. Whenever possible, one should work on the tree nodes and leave the xml nodes alone.
You’ll find lots of information on this in the inkscape wiki, e. g. “Changes in the XML tree are automatically propagated to the object tree via observers, but not the other way around—a function called updateRepr() must be explicitly called.
 
As the rdf information is not a drawable object (-> SPItem subclasses), it should probably derive directly from SPObject. Maybe you could then add it as a member to SPMetadata. I’m not quite sure how to handle that best either. We should wait for some more opinions… or just try it out :) .
 
Regards,
Markus
 
> Hi Markus
> I started work on Inkscape earlier this year (April/May). During the summer
> I work with Commons Machinery [1] to improve metadata handling and the GUI
> for metadata and license information. In this prototype I'm working with
> the idea that multiple metadata tags are allowed and therefore multiple rdf
> tags (though only one per metadata tag). With my limited experience with
> Inkscape codebase and the object tree I'm not sure how to best refactor RDF
> to fit in.
> 
> In an earlier discussion with Peter Liljenberg [2] he said that a refactor
> of RDF should be done to be more general and easy to work with. I'm not
> sure about the specifics about this but I will look into it later on in
> August hopefully.
> 
> You seem to have a lot more experience with the Inkscape codebase than I
> have so it would been fun to discuss any changes that is done here in this
> area with you. The goal now for me is to complete the prototype with as
> simple code as possible and then during the summer/fall (when time permits)
> refactor so it can be merged into Inkscape trunk.
> 
> Concerning GSOC merge before 0.49, I don't know.
> 
> [1] http://commonsmachinery.se/
> [2] https://launchpad.net/~peter-liljenberg
> 
> -- 
> Christoffer Holmstedt

> 


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel