Date: Fri, 12 Mar 2004 14:25:23 +0100
   From: Dave Neary <[EMAIL PROTECTED]>


   Robert L Krawitz wrote:
   > I'm the Gimp-Print project lead, that's why I asked the question :-)

   I know :) Sorry to hear the 5.0 release is still a bit away.

   > In the 5.0 tree, the plugin has been split into two pieces, a UI
   > library (libgimpprintui) and the GIMP plugin proper (which is tiny,
   > and contains all of the GIMP-specific code).  We should work out the
   > appropriate ownership of of these two components, and the correct
   > dividing line.

   It would be really great if you would continue to maintain the
   gimp-print plug-in that's in GIMP CVS. Understandably, since
   gimp-print is now very much its own project, our release schedules
   aren't going to match up for the most part, but currently the goal
   would be to support the latest stable release of gimp-print in the

   Having 2 GIMP plug-ins (1 in gimp-print that's based on the last
   stable GIMP and another in the GIMP that's based on the last stable
   gimp-print) doesn't really make sense. I would propose that the
   gimp-print plug-in gets updated in the GIMP tree when the libgimp
   API changes, and then gets updated to use the new gimpprint when a
   stable release comes out.

The current plugin (based on 4.2) is basically in sustaining at this
point, and really approaching EOL.  We're hardly even fixing bugs in
4.2 any more.  We're probably going to do one more 4.2 release for a
few bugs, an OS X problem that isn't a Gimp-Print problem but which
gets blamed on it, and a couple of new Epson printers.  But that won't
cause you any problems.  I'm not going to remove it from our source
base, since there will be very few 4.2 releases left.

The plugin in our 5.0 tree is another matter.  Since the 5.0 API isn't
locked down, it's premature (IMHO) to transfer it to the GIMP.  There
are major structural changes from the 4.2 plugin; in particular, it
has been split into two pieces, libgimpprint and the Print plugin

libgimpprint is a GTK+ (1.2 right now) UI, without any linkage to
libgimp.  The GIMP-specific code is in the plugin, consisting of 4
files of less than 1000 lines of code:

    457    1492   11003 print-image-gimp.c
    425    1418   13702 print.c
     55     222    1590 print_gimp.h
     38     199    1372 print-intl.h
    975    3331   27667 total

The question is what should be transferred to the GIMP when our API
stabilizes.  Certainly the core GIMP plugin is a good candidate, but
libgimpprintui is less clear.  It's actually much larger than the
plugin proper (and badly in need of cleanup).  It could at least in
principle be used as a print facility by other GTK-based
applications, although it's not completely general (it only handles
single pages).

   4438   12230  136157 panel.c
   1371    3945   36094 plist.c
    155     465    3964 print-image-thumbnail.c
     44     215    1385 printrc.h
    105     382    3287 printrcl.l
    285     654    6321 printrcy.y
    869    2482   25134 ui-utils.c
   7267   20373  212342 total

(I'd ideally like to support both a 4.2 and a 5.0 plugin concurrently,
because people who have built workflows around 4.2 may not want to
switch in one shot.)

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