On Mon, 2008-08-11 at 17:28 +0100, Peter TB Brett wrote: > Lots of bits snipped out to keep message a sane length. > > On Monday 11 August 2008 16:58:31 Bernd Jendrissek wrote:
[snip] > > 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). May have been me, but it was possibly more about signaling overheads than anything else. [snip] > > 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... Scary. > > > 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. It's actually debatable if you'd want a file-change on disk to update the picture in gschem. An "update picture" command would of course want to reload from disk, as would a schematic reload (for non-embedded images). Yes.. I was just throwing ideas about. No time to code them up though unfortunately. I would quite like to get Gdk* out of libgeda though. Of course... the _real_ reason it is hard to kick out, is that GdkPixbuf is used to extract RGB data for the image in the printing code, which lives in libgeda. (Gdk Eviction fails). It's shame we can't just embed arbitrary encoded image data into the .ps output. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
