Kevin Cozens <[EMAIL PROTECTED]> writes:
> I'm not sure what the difference is between Script-Fu and the
> "abstract PDB language". DB Browser, IMHO, should allow you to see the
> names of functions/plug-ins, a list of the arguments that are
> required, what each argument is for, and the range of constants (by
> name and value) that can be used for each argument. It could (should?)
> also include any useful notes such as gotchas, limitations, conditions
> of use (for the function or argument), or generally useful tidbits of
> information akin to the type of stuff in "tip of the day" that you see
> on startup. ie. the function that creates a new image could have a
> note saying to use the function to create a new layer as the next
> logical/typical thing to do.
> This descriptive included after the argument list should be kept short
> and not be a simple re-iteration of what you can learn from the
> argument information above (as is the currently the case for a number
> of function descriptions).
> The DB Browser should not include examples of the invocation of a
> given function. I think that would get too much in to the specific
> syntax for a given plug-in language. That should be considered beyond
> the scope of the contents of DB Browser. Language specific information
> should be part of the help system of the GIMP or more likely in
> external documentation.
Actually I don't think DB Browser is actually very well suited for
this job. The API reference is a lot more useable already although
perhaps it lacks the search capabilities of the DB Browser. However
you will have noticed that the API reference manuals contain basically
the same info as displayed by the DB Browser. This is because it's all
generated from the same source. So the best thing to do if you want to
improve both the API docs and the DB Browser is to send patches to
improve the PDB documentation.
In the long run we plan to revamp the PDB. When redesigning the PDB,
documentation should play an important role. I don't think it makes
sense to stick to procedures that are defined and documented in C
code. A procedure definition could be an XML file or some simple s-exp
syntax. Such a file could contain elaborate descriptions that wouldn't
have to be compiled into the GIMP application but could be parsed on
demand by the DB Browser and the tools that generate the API reference
> I won't make any changes related to DB Browser information until it
> is confirmed that changes are needed, what they need to be (at least
> in a general sense. ie. move things towards language X), and which
> files need to be updated (ie. ones ending in .c or is it .pdb with
> the .c files generated from that?).
Perhaps you want to read HACKING. It will answer at least some of your
Personally I don't think the information displayed by the DB Browser
should be changed towards any language. The GIMP language bindings
will always have a different syntax and I don't see why the DB Browser
should favorite a particular language. Changing the DB Browser will
most probably lead to more confusion than it would be helpful.
Gimp-developer mailing list