On 6/16/07, Gail Banaszkiewicz <gbanaszk@...1686...> wrote:
gchar * href;
this just stores the string from xlink:href attribute
SPUseReference *ref;
This is the actual reference to the origin object, which has the added convenience: it does not require that the origin object even exists when you set up the reference. This way, when you read a document, you can safely set up the ref of a clone even if the object it refs is below it in document order, i.e. does not yet exist when you build the SPUse. After the reffed object finally emerges, the URIRerefence senses that and sorts everything out.
sigc::connection _delete_connection; sigc::connection _changed_connection; sigc::connection _transformed_connection;
And these are just signal connections that notify the SPUse when something happens to its origin object so the clone needs to update itself.
But SPUseReference is in fact a subclass of URIReference. Does having this make the other members redundant to a point?
No, because URIReference does not notify you when some change happens to the reffed object. The only goal of URIReference is to reliably resolve the URI, i.e. go from the URI string to the SPObject pointer if this is at all possible. For everything else, you use signals.
Similarly, SPTextPath uses a subclass of SPUseReference called SPUsePath, which contains all the same sigc::connection stuff that is stored in SPUse.
And for the same reason: text-on-path needs to update itself when the path it refers to changes.
Is it possible that SPUse could strip itself of the connection stuff and maybe even the href (not sure exactly the need for that one) by replacing the SPUseReference with SPUsePath?
No, as I explained above. Besides, a clone can refer to any object and not just path, whereas a text-on-path can only be linked to a path. This is the reason why there are two different subclasses of URIReference used.
Most importantly, is there any reason that SPTRef could use SPUsePath to refer to the element it will take character data from?
It should use yet another subclass of URIReference that you need to create. Its sole difference from the others will be that it can only link up text or tspan objects. And yes, apart from that you will also need to link to the ::changed signal (but not ::transformed I think) of the linked text object to update your tref when the source changes.