If it's just a key and value, a std::map will be just fine but I'm not sure if that's the case just yet. If the value is a bag/list of other values this may turn into a problem. Maybe I'm looking at it in the wrong way and trying to force a mapping from each XML node to an object/class.

Concerning "building blocks" and "values". Building blocks for me are XML nodes such as rdf:RDF, rdf:Bag and rdf:li. These are used in several places to structure the metadata. Values are node such as dc:date which just has a value and that is it.

1) I will take a look. document-metadata.cpp is not used anymore since the metadata dialog was moved to document-properties.cpp maybe this functionality was lost during that refactoring process. I have another branch where I've removed all the dead code https://code.launchpad.net/~inkscape.dev/inkscape/document-metadata-code-cleanup I could merge it into trunk but I'm still worried that I have removed something of value.

2) Perfect. Will take a look at the updateRepr methods.

3) Thanks for clarification.

As a last note I will wait two/three weeks to start refactoring this as I'm leaving for my honeymoon trip this Sunday. When I get back the others from Commons Machinery is back from their holiday as well so I can get more feedback from them concerning the RDF/RDFa side of things.

Regards
--
Christoffer Holmstedt


2013/7/31 Markus Engel <p637777@...3029...1...>
I don't seem to get what you mean by "values" and "building blocks"? Is it
necessary to create a class just holding a key and a value? Wouldn't a
std::map suffice?

1)
The SPObject class exposes a method "connectModified" which you can use to
register a sigc::slot with the modification signal. This should work I hope.
Or look at "src/ui/dialog/document-metadata.cpp". Inside this file there's a
method called "on_repr_attr_changed":
/**
 * Called when XML node attribute changed; updates dialog widgets.
 */
I don't know why this does not work currently.

2)
Sorry? When the xml tree is modified, the corresponding SPObject is
automatically informed, I don't think you have to do anything there
yourself. When you want to update the xml node after you made a change to an
SPObject, just call the modified SPObject's updateRepr method.

3)
Yes, I think so. The SPObject will stay, not as a struct but as a real class
;) . For the moment you'll have to get into creating a derived GObject
"class". There is an example in sp-skeleton.cpp. I'm just waiting for the
0.49 release to propose for merging, as I made some big changes to the code
base with probably some nasty bugs.





------------------------------

Message: 7
Date: Wed, 31 Jul 2013 14:58:48 +0200
From: Christoffer Holmstedt <christoffer.holmstedt@...400...>
Subject: Re: [Inkscape-devel] RDF nodes
To: inkscape-devel@lists.sourceforge.net
Message-ID:
        <CAG9Fz+tsLNe019Y=qu5Miu4-YtmsQA5Ya9xKNuD=PP+cm9O+xw@...401...>
Content-Type: text/plain; charset="utf-8"

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****
>>
>> >** **