[snip]Constant names are a much smaller difference than calling conventions between languages. It is, in general, impossible to use an API for one language in another without adapting it to the target language.
I'd also find it cool if you looked into the DB Browser and made it "fully scheme" or "fully C", i.e. consistent at least to one language. However, the idea of having the same API, character-for-character, in all languages is futile. Don't bother with it.
DB Browser should be consistent for one language even if its just the "abstract PDB language". I don't think it should have different 'modes' to have it show things depending on a user selectable plug-in language. That would probably complicate things too much on the developer/documenter side. I would think that making it consistent to Script-Fu (scheme) would be the way to go. Everyone who has GIMP can create or modify Script-Fu scripts with only a text editor. Not everyone who has GIMP has a C compiler or even Perl. In particular, the Windows users and machines running IRIX 5.3/6.2 to name two examples of systems that could run GIMP but don't come standard with a C Compiler. And yes, I know such things are available but one has to have a need/desire to get a C compiler or Perl interpreter for those environments.
[snip]Changing script-fu to comply with this sounds ok, changing the Browser to comply with script-fu is better, but more difficult (right now it's a mix of both, or maybe the "abstract PDB language"?).
Perl specifically has a tool named gimpdoc, which shows calling conventions in perl, e.g.:
layer = gimp_layer_new (image,width,height,type,name,opacity,mode) layer = $image->layer_new (width,height,type,name,opacity,mode)
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.
One could also argue that the DB Browser does things the "abstract PDB" way, and is fine this way, although a bit unspecified, as long as rules exist to convert them to specific implementations.
The rules should be specified (if they aren't already) somewhere in documentation should be easy for a user or new developer to find.
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?).
Cheers!
Kevin. (http://www.interlog.com/~kcozens/)
Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include <disclaimer/favourite> | -Pinkutus & the Borg
