Hi, Kevin Cozens <kcozens@xxxxxxxxxxxx> 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 manuals. > 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 questions. 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. Sven
