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?

From: Michael Natterer
Date: 14 Jan 2003 11:00:49 +0100

Robert L Krawitz 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.

Excellent.

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 Gimp-print.

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 user.

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 that.

From: Sven Neumann
Date: 14 Jan 2003 14:27:22 +0100

Robert L Krawitz writes:

> 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.

I think it would have been wise to discuss this step with the GIMP developers beforehand. I haven't looked at your code so I don't know which parts you "cribbed" but it seems like a bad idea to have the same code in two places. Before you rip code out of a library you should at least contact the authors. Perhaps there's a way we can avoid maintainence nightmare and make these widgets available to other projects instead of forcing more people to copy the code.

Good point.

The specific parts that we borrowed are:

gimp_table_attach_aligned gimp_scale_entry
gimp_option_menu
gimp_dialog

This is still on the development tree, so we have plenty of time to work out a better way of doing this.