From: Michael Natterer <mitch@xxxxxxxx> Date: 14 Jan 2003 11:00:49 +0100 Robert L Krawitz <rlk@xxxxxxxxxxxx> 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. -- Robert Krawitz <rlk@xxxxxxxxxxxx> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lpf@xxxxxxxxxxxx Project lead for Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
