Cc: gimp-print-devel@lists.sourceforge.net From: Roger Leigh
Date: Mon, 24 May 2004 01:18:30 +0100

Robert L Krawitz writes:

> From: Roger Leigh > Date: Sun, 23 May 2004 14:03:36 +0100 >
> Does anyone know how (for the Debian packaging) I could build it > statically? configure allows --enable-shared=lib1,lib2 and > --enable-static=lib1,lib2,... but this doesn't work as I'd like: if > you say you want a library built one way, it builds every other > library the opposite way. For example, if I do > --enable-static=gimpprintui, every other library is dynamic only. > What I'd like is everything built both dynamically and statically, > except for libgimpprintui, which should be static only. I'd like > to do that or link print with the static version. >
> The reason for this is that I don't want two extra packages > (libgimpprintui1 and libgimpprintui-dev) unless there's actually a > use for them, and I don't believe there is at present. >
> Why would it force a separate package?

If the library is shared, it needs to be in a separate library package, and the headers and static library need to go in a development package. If it's static-only, I can just link it with the plugin and not package any libraries at all. This isn't strictly required AFAIK, but is the recommended practice, since if the library is packaged with a program, it makes it harder for other packages to depend on it, since you force the user to have the program it is packaged with installed, whether they want it or not (e.g. including GTK+ in the GIMP package).

(The point is moot for the 1.2 plugin, since GIMP 1.2 is not available in Debian any longer, but the same might need to apply to the new libgimpprintui, at least initially.)

So I think I've finally figured out how to factor the GIMP plugin. This may be of interest to the GNOME and KDE folks, also.

Bottom line: the GIMP folks should own src/gimp (the GIMP-specific code), and we should own libgimpprintui (which should be renamed libgimpprint-gtk2 for the gtk2 version). The advantage of this is that we can upgrade the plugin to take advantage of any new features in Gimp-Print (profiles, what have you) without GIMP users having to even recompile the plugin. For this to work, obviously libgimpprintui *must* be dynamic.

So what do we need to do for this to be practical?

1) I need to finish what I'm doing, which is what I proposed last week (and nobody took me up on), to clean up the queue-handling stuff. For coding I'm probably 50-75% there. I created a new CVS branch for this.

2) We need to define exactly what the interface is between the GIMP and libgimpprintui (i. e. the stpui layer). This should be a very thin layer, certainly much thinner than libgimpprint and possibly even thinner than what it is now. We may even want to not expose the libgimpprint layer at all to the plugin.

Part of this is making the stpui_plist_t opaque, like we've done for the various "classes" in libgimpprint. Whatever we do, I don't think we're far away here.

3) Roger and/or Jody need to finish their libgimpprintui2/libgimpprint-gtk2 port.

If we do this right, then we can change libgimpprint to our heart's content and the GIMP plugin will go merrily on its way, without ever having to be recompiled or relinked. When the GIMP supports 16 bits, only the plugin needs to change, and that would be owned by the GIMP. If we add color management, then as long as we don't rely on the GIMP for any of that there should be no problem. Then when we go to 5.2 or even 6.0 or whatever GIMP users shouldn't have to worry about an upgrade.

The KDE and GNOME folks may find this kind of thing interesting. For example, if KDE wants to offer Kimp-Print as an alternate (richer) printing KPart that isn't limited by what PPD files can describe, but can take advantage of Gimp-Print's functionality, they could write their libkimpprint and do the same kind of thing.

What do folks think?

From: Sven Neumann
Date: 25 May 2004 11:19:10 +0200

your post (and other mails on the gimp-print-devel list) make me believe that there isn't much hope for a stable gimp-print API to appear during the next weeks. Is that right? This means that we have to change our plan to ship gimp-2.2 with an updated print plug-in. It also means that we need to apply the latest user interface changes to the print plug-in also. So far we haven't touched it since it was scheduled for replacement.

The core API's pretty close, but we're probably not quite ready to go beta. However, we're not that far off, either. What's your plan for 2.2?

This also brings up a problematic point about libgimprint-gtk2. Such a library that includes the complete GUI will make it impossible for us to have a print plug-in with a user interface that is consistent with the rest of the GIMP UI. Of course you could adapt our user interface guidelines (which are basically the HIG with some twists) but we could always change our mind on this with the next GIMP release (just like we just did, GIMP-2.2 will look different than GIMP-2.0). Also other projects using this library might have other ideas about the look and feel. So you can't possibly get it right for everyone unless you use lots of style properties to make every aspect of the GUI themable.

Good point. I hadn't thought about that aspect of it; I was looking at it from the Gimp-Print side.

Perhaps it would be better to not have the actual user interface in a gimpprint library. If you want to make it easy to write a GTK2 GUI on top of libgimpprint, then you could provide a model on top of libgimpprint that people can easily write a view for. This library could provides GtkListStores for any selection the user needs to make, it could provide a preview widget to position the image on the paper. Basically it would just nicely wrap the libgimpprint API and make it more GTK+ friendly.

That would be a possibility.

From: Sven Neumann
Date: 25 May 2004 10:54:00 +0200

Robert L Krawitz writes:

> If we do this right, then we can change libgimpprint to our heart's > content and the GIMP plugin will go merrily on its way, without ever > having to be recompiled or relinked. When the GIMP supports 16 bits, > only the plugin needs to change, and that would be owned by the GIMP. > If we add color management, then as long as we don't rely on the GIMP > for any of that there should be no problem. Then when we go to 5.2 or > even 6.0 or whatever GIMP users shouldn't have to worry about an > upgrade.

I doubt that you can foresee any changes that might be needed in the future so I am not completely sharing your optimistic view on this. But in general it seems like the right thing to do. Nevertheless I'd like to have a look at the proposed libgimpprint-gtk2 API before it's finalized. Could you please post a header file here?

Certainly we'll do so if/when we do this (it was a proposal). My hope is that the GIMP isn't going to have a lot of changes that would require changes to this hypothetical libgimpprint-gtk2. For example, if you were to support floating point channel values, the plugin could convert those to 16-bit unsigned integers.