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
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 -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gimp Print -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
Gimp-developer mailing list