On Wed, 5 Jan 2005 18:39:05 -0500, Brandi Soggs <soggsbh@...635...> wrote:

1. Every time that a user changes an object, we will need to make the same

change on the same object in for the other users. For our purposes, document changes are visible changes- changes to the objects drawn or the creation of new objects. We've seen in the documentation that there is no central place that gathers changes. Ishmal suggested to us that we use the sp-canvas as an area that always gets "hit" by document changes. When a change reaches the sp-canvas, does it actually know all the details (what happened to which sp-item) or does it just know "A change has occurred! Redraw!" ?

No, SPCanvas is way too low in the hierarchy for your purposes. I think what you need to watch is the SPRepr system. It's similar to DOM, i.e. it stores a representation of the source document, and is changed whenever everything is changed on canvas and elsewhere (and remember that "invisible" changes may affect visible objects, e.g. if you change a gradient definition in <defs> that will change all visible objects that use this gradient). Also reprs are what maintains the undo stack, so in principle you can hook into sp_document_maybe_done (a function which is called as soon as an undoable action is finished) and sync your repr copy with the master repr tree. Or you can look into the topmost undo stack record and see what exactly has changed. Or, if you are interested in one particular node, you can attach a listener to that node and you will be called whenever that node changes.

2. We're curious how and where (both the techinque and the place in the

code) object ids are generated. We've had some trouble tracing it ourselves. We're going to need to control object id generations well enough to prevent two users from attempting to make two objects with the same id.

When sp_object_invoke_build is called (which happens both when the object is built from source on document load and when a new object is created), it runs sp_object_get_unique_id. That function checks if there is already an object with that id and if so, generates a new unique id and assigns to that object, otherwise leaves the old id alone and returns.

3. We're not certain how all of the arguments to the functions

(sp_item_build, sp_item_set, sp_item_write, sp_item_commit, sp_item_transform, and equivalent functions in sub-classes of sp-item). Presumably these arguments are the actual details of a change that has occurred.

SPItem is a subclass of SPObject. SPItems represents all objects that are visible on canvas. All SPObjects, in turn, are generated from SPRepr nodes (though one repr may have more than one SPObject attached to it). All the functions you listed are standard methods of SPObjects and its subclasses, that are called at various stages of their lifetime, not necessarily associated with some user action.

For example, sp_item_write and other *_write functions update the repr of this object, i.e. if the object has changed they bring the repr to sync. This may happen in lots of different situations, and the different levels of hierarchy handle their corresponding aspects of repr updating.

For example any SPObject must have an id, and therefore sp_object_private_write writes the object's id into its repr:

sp_repr_set_attr (repr, "id", object->id);

Then, if this spobject is also an spitem, sp_item_write runs. It sets those attrs which are common to all visible items, i.e. transform and style.

Then, SPRect is a subclass of SPItem, and sp_rect_write updates those attributes which are specific to rects (x, y, rx, ry). It does not have to worry about the id or transform because that was already taken care of by its parents.

Similar hierarchies work for other standard methods (build, write_transform etc). However, you probably don't need all this. What matters for you is that SPRepr ends up with complete updates from all changed objects, and you can take what you need from there. It's the easiest for those new to the code, because the SPRepr tree is the closest thing we have to the actual SVG code, yet it is always up-to-date in memory (e.g. the XML editor is simply a visualization of the SPRepr tree).

P.S. I'm posting a copy to the inkscape-devel list, hope you don't mind. Please feel free to ask any other questions on that list, me and others will be glad to help.