Hi,

"William Skaggs" <[EMAIL PROTECTED]> writes:

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

Why is this bad? There are plug-ins that are supposed to be completely
non-interactive. You call them from the menu, they do their job. What
is bad about that?

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

The problem is that the "blurb" and "help" strings as they are
registered with the PDB are (a) not meant to be user help and (b)
missing or not helpful in almost all plug-ins. Also these strings
would have to be translatable. This could be easily changed but before
you call for translation there would have to be reasonable strings.

We tried this approach for Script-Fu scripts (w/o the translation).
I don't think it works very well.

> It should also have a "Help" button that invokes the help browser
> with the main help page for the filter.

This could be discussed. Basically since we have help IDs with every
dialog, we could have a help button everywhere (and we wouldn't need
any API changes to do that). But then we are often short of space in
the dialog action area. Last time we discussed this we went for not
adding Help buttons. The idea was that F1 would be good enough to get
to the Help. Of course we could review this decision.

Please excuse if I may sound demotivating. I am only trying to explain
the reasoning behind the current state and problems that I see with
your suggestions. I am perfectly willing to discuss this further.


I'd also like to add that in we plan to redo the way that standard
filters create dialogs. When we get a new PDB API where plug-ins
register named parameters with default value, range and a blurb, we
can construct a user interface from that similar to what (but not how)
Script-Fu does it now. With some extra info more complex user
interfaces could be build. The beast prject has some code that does
this and perhaps we could use it or implement a similar approach. For
a plug-in author this would mean that unless the plug-in needs
non-standard widgets, no GUI code would have to be written at all.


Sven
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to