Re: [Sodipodi-list] Sodipodi extensions - status

[Lauris K. <la...@ka...>]

Hello!

On Thu, 2003-01-30 at 23:07, Bryce Harrington wrote:
> On 30 Jan 2003, Lauris Kaplinski wrote:
> > I once implemented much more generic DOM-like configuration frontend
> > in libgnomeprint. With little tweaking this should allow us to
> > implement almost universal interface for user-modifiable data,
> > including window positions and like. I am still thinkning, whether
> > to bring it into sodipodi or not.
> 
> I seem to recall seeing some comments in the code about another DOM.
> The one that's there is okay, though it could use some documentation.
> ;-)
> 
> It does seem to be lacking some helper operations for complex data
> structures, such as a good routine for counting # of objects in a list,
> etc.  But I was able to get it to do what I needed.  Again,
> documentation would help - I had to trial and error and grep through the
> codebase for examples.  I found it an interesting puzzle.  ;-)  Others
> might find it more frustrating, though.
> 
> If you do keep it, you might want to review the interface.  There's a
> couple routines advertised in the .h that are not actually provided, or
> that are just stubs.

Well, this is wild idea just now...

> > const unsgined char *roundh = "Extensions.ObjectConverters.RoundHole"
> >
> > and perform lookup before each (batch of) data access(es)
> 
> Not quite sure I follow the meaning here.

The question is - do you have to keep handle to extension metdata? If 
yes, this should not be pointer to SPRepr, unless managed by higher
level object. Instead you keep the path of given node in sodipodi
extension/config tree.

> There isn't any user manipulation of the extension metadata, nor were
> there any tangible plans for this that I recall.
>
> I had initially looked to implement the registry as a hashmap that would
> live in memory.  (That's how I typically handle such problems in C++ or
> Perl.)  Since it appeared that for preferences, the standard was to use
> SPRepr, I stayed consistent.  So if you choose to do preferences in a
> different fashion, you can also change the extension code to do
> similarly.

Best wishes,
lauris Kaplinski