Hi, "William Skaggs" <weskaggs@xxxxxxxxxxxxxxxxxxx> 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
