Hi,
I have been thinking about how to improve the consistency of the
user interface for plug-ins, and have come up with a tentative plan
and the mechanism for implementing it, which I will outline here to
see if people think it is reasonable and workable.
First, though, a little terminology. As I will use the terms, a
"plug-in" is an external executable that interacts with the Gimp core
via the plug-in mechanism. A "filter" is a plug-in that changes a
drawable in some way. Only some plug-ins are filters -- there are
others that read or write specific file formats, set the foreground
color, interact with the PDB, etc. The plan I will describe here
really only applies to filters -- other types of plug-ins may well
call for other types of interface.
There are two basic principles behind the plan. 1) Every filter
should produce a dialog when called interactively. At the moment,
some just do their thing without showing any dialog: this is bad. 2)
The dialog should contain three standard buttons, "About", "Cancel",
and "Okay". The "Cancel" and "Okay" buttons should do the obvious
things; the "About" button should pop up a dialog that shows the
"blurb" and "help" strings for the filter, as entered into the PDB.
It should also have a "Help" button that invokes the help browser with
the main help page for the filter.
I have written a set of functions that make it easy to implement
these things in a plug-in. Three of the functions are public:
gimp_filter_dialog_info_new(), gimp_filter_dialog_new(), and
gimp_filter_dialog_run(). They would typically be used in the
following way:
{
GimpFilterDialogInfo *info;
info = gimp_filter_dialog_info_new (procname, /* PDB identifier */
_("Filter"), /* for title bar */
help_id,
help_func);
dialog = gimp_filter_dialog_new (info);
/*
* Set up the dialog (which is a GimpDialog) by
* packing its VBox with controls.
*/
run = gimp_filter_dialog_run (info); /* main loop */
/* if run=TRUE, run the filter */
}
Note that this is very nearly the way things are done in a standard
plug-in now, so converting one to the new system is about a
five-minute job. (I've done it to a few to test.) The advantage,
then, is that with a type of dialog specifically for plug-ins (as
opposed to GimpDialog, which is used for many purposes), changes can
be made in one spot that affect the appearance of all filter-plug-ins
without having messy side-effects. For example, in my code the
"About" button has a simple text label -- replacing it with a stock
item would be a one-line change.
As I said, I have written and tested code to do these things (two
files, gimpfilterdialog.c and gimpfilterdialog.h, which would go into
libgimpwidgets). I'll be happy to supply it on request, via Bugzilla,
mailing list, or email. I would include it here, except that I would
be pushing tolerances for mailing list email length.
This stuff is of course not suitable for 2.0. My thought is to submit
it for 2.1 after branching if people think it is a good idea.
Best,
-- Bill
______________ ______________ ______________ ______________
Sent via the KillerWebMail system at primate.ucdavis.edu
