On 6/2/06, Hugo Rodrigues <haa.rodrigues@...400...> wrote:

At the moment I'm building up the SPFilter classes. It would be most helpful if you could provide an overview of how different objects interact.

That's a huge topic :) I will cover some basics now, but the best you can do is join our jabber chat and ask your questions there. Most of the time there are people there who will be able to answer your questions, or at least give some useful pointers.

From what I understand, some callback from the UI should create the SPFilter,

No, it's the other way round. SPObjects are created by the XML tree (which we call "repr" tree) of the document. Each element in source SVG creates a repr (branch in the repr tree, an object of the class Inkscape::XML::Node), and each repr creates a corresponding SPObject. A repr stores information in attributes and their values, so it corresponds 1:1 to the source XML, but SPObject may store its information in any convenient way.

The correspondence between repr names and SPObject types is in the file sp-object-repr.cpp. Add your new SPFilter object to it, then load an SVG file with a filter, and that should trigger the creation of an SPFilter object upon load.

Most of the time information goes downstream from repr to SPObject. Whenever an attribute of a repr changes, its SPObject's set method gets called with the new data. This method should parse this information and store it in SPObject's fields, and if necessary call display update.

which in turn is responsible for updating the respective XML node, everytime a change is made to the filter.

Most of the time it's the repr that updates the SPObject, not vice versa. However the reverse update is also possible: each SPObject has the write method which updates or creates the repr from the SPObject. But this is used mostly during save to plain SVG when all the repr tree needs to be recreated.

I also presume that this XML component is not of much use for Niko, since he gets the data to display from the SPFilter.

Yes

This means I shoud focus on having a decent SPFilter object before anything else, and then proceed with XML creation...

As I said repr is created automatically, and at first you can do even without a write method in your SPFilter. The set method is much more important.

(or correct) these thoughts, and define some milestones so that I can make sure I'm developing things on the right order and that Niko always has the structures he needs from me.

The obvious first step is to have SPObjects created for all filter elements and make sure the information is correctly transferred from SVG into the members of these objects.

Could you also clarify the purpose of the 'flags' argument, found in most SPObjects' functions (what are they used for, should I worry about them,...).

They are used in update propagation, i.e. affect screen display. For now you may ignore them.