From: Roger Leigh <[EMAIL PROTECTED]>
   Date: Mon, 24 May 2004 01:18:30 +0100

   Robert L Krawitz <[EMAIL PROTECTED]> writes:

   >    From: Roger Leigh <[EMAIL PROTECTED]>
   >    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

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?

Robert Krawitz                                     <[EMAIL PROTECTED]>

Tall Clubs International  -- or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gimp Print   --

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Gimp-developer mailing list

Reply via email to