>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.
I was actually aware of that. I've actually already written meaningful
pdb-help for about 1/3 of the relevant plug-ins -- it takes about 5 minutes
once you understand what the plug-in does -- and am ready to do it
for the rest if I have some reasonable confidence that I'm not wasting
my time. (I've been trying to understand what plug-ins exist and what
they do, and in the course of this it just seemed natural to write down a
brief summary for each one I looked at.) Of course by this I don't mean
a full help page, I just mean information enough to tell a user what the
plug-in does and whether it is likely to be useful for the current need.
>> 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.
Yes, I know it's redundant, but (a) it's very easy, and (b) the help button
is not on the main dialog, only the "About" dialog, so it doesn't add
clutter for practical purposes. Certainly not essential, but friendly
to new users. (Incidentally, most plug-ins are very lacking in help-id's;
I've been adding some as I go.)
>
>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 have anticipated these points, and a few others you haven't mentioned
yet, but didn't want to make an already long email longer by trying to
discuss every possible aspect at once. Let the discussion continue!
>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.
Well, I think that what I am suggesting is a step toward this, and would
actually make it easier when the time comes.
Best,
-- Bill
______________ ______________ ______________ ______________
Sent via the KillerWebMail system at primate.ucdavis.edu
