From: Michael Natterer <[EMAIL PROTECTED]>
   Date: 14 Jan 2003 11:00:49 +0100

   Robert L Krawitz <[EMAIL PROTECTED]> writes:

   > I'm looking for a volunteer to work on some user interface issues with
   > Gimp-print.  Specifically, we're introducing a lot of very powerful
   > new options in 4.3, and I'd like to find someone with a good grasp of
   > human factors to work this into the user interface.  Anyone
   > interested?

   I'll continue to update the plug-in's GUI according to upcoming
   gimp-print changes. I don't quite recall whan decision we made a
   while ago about where to keep the plug-in's source. IIRC we wanted
   to keep it in the GIMP CVS only, but I have surely no problem to
   check in the changes into gimp-pring CVS as well if the decision
   was to keep the plug-in around there.


>From a structural perspective, we've split the plugin into two
components: libgimpprintui, which is the UI framework, and the plugin
itself.  The plugin core is quite small, and it's intended to be
replaceable by anything else that wants to provide print services
(e. g. a standalone print utility).  This core (which provides the
interfaces between the GIMP and libgimpprintui) should eventually
migrate over to the GIMP.  The UI library should stay part of

You'll notice that we've cribbed some code from libgimpui into our UI
library.  This consists of some of the GIMP widgets that are just too
useful to pass up.

Beyond that, you should take a look at include/gimp-print/gimp-print.h
(and for that matter include/gimp-print/gimp-print-ui.h) on the
mainline.  In particular, take a look at the stp_parameter_t.

   Also, I didn't follow gimp-print-developer discussions that closely
   the last few month (you guys produce a whole bunch of stuff to read
   :), so I'll need some hints on what exctly the upcoming changes are
   and if you already have thoughts about the GUI extensions.

The big changes to date are:

1) There are a lot more different options, and the set of available
   options can vary by printer model and by other selected options
   (eventually there may be a choice of different color models, such
   as Classic Gimp-Print, ICC Profiled, etc. which may also support
   different options).  The set of options can be queried, and the
   individual options can be "described" in more detail.

2) Options are typed: they are either string-list (a string chosen
   from a list), curve, filename, float, integer, boolean, or raw.
   These types can be used as UI hints (for the type of control
   widget), in addition to the more obvious use.

3) Options are classed: they can be for page size, printer features,
   output control, and others that we may come up with.  This is
   intended as a UI hint.

4) Options have levels: they can be basic, or advanced at different
   levels.  This is intended as a UI hint.

5) Options can be inactivated: a given printer/color model may support
   these options, but may not be using them with a given choice of
   parameters.  This is intended as a UI hint.

I've done some UI stuff, such as making various things resizeable.
You may want to take a look at that.

There's a lot of stuff in here, such as curves, that will (or should,
at any rate) Just Work if the UI is brought up to date.  I'm doing
more changes on the mainline (moving the CMYK generation into the
color code, for example) that will expose more options to the advanced

We also need to come up with a new printrc format.  I'm thinking about
whether we want to move this (at least the format) into core
libgimpprint, so that it can serialize and restore (as ASCII text) an
stp_vars_t object, but for now the printrc handling is in
libgimpprintui.  This new format needs to handle the different data
types.  There's already a print format defined for curves.  We may
want to consider an XML-based format; Roger Leigh is our expert on

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