Lots of bits snipped out to keep message a sane length. On Monday 11 August 2008 16:58:31 Bernd Jendrissek wrote: > On Mon, Aug 11, 2008 at 3:34 PM, Peter Clifton <[EMAIL PROTECTED]> wrote: > [snip] > > > 1. > > libgeda OBJECTs could provide one or more slots to stash arbitrary data > > associated with objects. (void * / gpointer). If we allow multiple > > "frontends", these will have to be associated by string / key / atom. > > I think GObject would make this easy, but from previous iterations of > this discussion I know that idea doesn't have much traction here.
FWIW I quite like GObject. I can't remember who it was who was objecting
(probably Ales -- I do remember that the main objection was the boilerplate
required).
> [snip]
>
> > Thinking about the pixmap problem a little further, and without reading
> > code to check feasibility, I wonder about this:
> >
> > libgeda keeps filename / raw data buffer, scrap out the pixmap storage.
> >
> > Gschem does not stash a pixmap directly against each object, instead:
> >
> > 1. Creates / loads the pixmap from the raw data, or from the specified
> > filename.
> > 2. Pushes that pixmap into a cache, hashed against the filename, or a
> > checksum of the raw data.
> > 3. Looks in it's cache for an already loaded pixmap when it comes to
> > render an object.
>
> That would take care of PICTURE::original_pixmap. Store a tuple in
> the hash to get PICTURE::current_pixmap too.
Yes, this is an idea I had floating around in my head this morning. I think
Peter Clifton and I thought alike...
> > Yes.. there are some details in there I'm not 100% clear on, such as
> > invalidating the cache if a backing-store file changes, or evicting
> > pixmaps when objects are deleted. These would require better lifetime
> > tracking / change notification from OBJECTs.
>
> Current libgeda doesn't deal with these issues either (IIRC) so I
> wouldn't want to hold a patch to the higher standard of having new
> feature X (tracking changes to the image file).
I agree entirely. Of course, the minimum is to match current functionality,
but I think Peter was just throwing ideas around. One advantage of doing that
kind of thing in gschem is that gschem has a main loop and can take better
advantage of things like inotify for watching for file changes.
Peter
--
Peter Brett
Electronic Systems Engineer
Integral Informatics Ltd
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
