Re: gEDA: Schedule for the next release of gEDA/gaf

[Mario Klebsch <mario-at-NOSPAMklebsch_dot_de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

> Just suppose for a moment that we move all the gdk function calls to
> gschem.
> For normal images, libgeda will have to store the filename path in the
> struct, (as it's doing now) and gschem will load the image, instead of
> finding it already loaded by libgeda (as it's now).
> For embedded images support, libgeda will need to load the image data
> into memory, and gschem should handle the conversion from ascii to a
> GdkPixBuf struct. No problem here if we do it this way.
> Now think about printing images. Right now, printing to PS and PNG is
> done by libgeda. If all gdk function calls are in gschem, libgeda will
> not be able to handle the images (it won't be linked against gdk 
> neither
> gdk-pixbuf), so only gschem will be able to print.
> Moreover, the print support will be splitted between libgeda (for all
> non-picture related objects) and gschem (for picture related objects).
> I don't think this is a good idea.

I do not thing, that printing should be handled in libged at all. IMHO 
it is more related to the editor (gschem), It makes every application 
dealing with geda schematics not oly dependand on libgdk but also on 
libz and libpng.

73, Mario
- -- 
Mario Klebsch                                           mario@klebsch.de
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB  1483 30CE 9FB2 A047 9CE0
  Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5  8B98 9464 53FF 9382 F518
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCIJpmMM6fsqBHnOARAgf+AKCbwjPCyFR05H8/5Wf9MuR76zLyAwCfWFc7
iLIk5IHfvekicQzPlwTg2v4=
=hKc2
-----END PGP SIGNATURE-----