Hi Ales, [snip] > The fix I had in mind was to call gdk_init only in gschem and then > move all the gdk_* calls out of libgeda/noweb/o_picture.nw. The other > apps (gnetlist etc...) when they encounter a picture simply should not > try to init/use the picture data. Now in gschem, since gdk_init has been > called and the gdk_* routines have been linked in, then yes, the picture > data should be initialized/used/manipulated etc... > > The only reason I'm advocating this is because libgeda does not > currently depend on the libgtk* libraries at all, only libglib. As shown by: > > $ pkg-config libgeda --libs > -Wl,--export-dynamic -L/home/ahvezda/geda/lib -lgeda -lguile -lguile-ltdl > -lqthreads -lpthread -lcrypt -lgdk_pixbuf-2.0 -lm -lgobject-2.0 -lgmodule-2.0 > -ldl -lglib-2.0 > > I don't think that libgeda should depend on gdk_pixbuf either. There are > no gtk_* calls in the libgeda library. > > If this is too painful, please let me know. I'm quite willing > to be flexible at this point in time and just say "forget it", all > gEDA/gaf programs should link against gtk+ (even CLI proggies...) Comments? >
I agree that the CLI apps should not be linked against gtk, neither call to gtk_init, since they are not GTK apps. The CVS version is fixed, and the call to gdk_init (not GTK) is made by libgeda if needed (therefore libgeda needs to be linked against gdk and gdk-pixbuf by now). There is no need to link against GTK. The GDK library is a graphic manipulation library, and it can be used by CLI apps as well, as they can use glib. It's not specific of GUI programs. I've been looking at how to move the gdk function calls to gschem, and I don't see how to do it in a clean way. I plan to add image embedded support, as well as printing to PS and PNG. 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. The CLI programs doesn't need to be linked against GTK, and they weren't changed at all after adding picture support. The only difference is that libgeda needs now gdk and gdk-pixbuf for doing all the picture related stuff. gdk is a graphics manipulation library, and its use is not limited to GUI programs, so I think that it's reasonable that libgeda depends on it if it has picture support. I'm not a geda expert, so maybe there's another way of doing this that I didn't think about. So, please, if you have any idea, I'd love to know. Regards, Carlos
