At 08:24 PM 01/30/2004, Marc Lehmann wrote:

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.

[snip]

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.

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"?).

[snip]

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 | -Pinkutus & the Borg

At 12:58 PM 02/02/2004, Marc Lehmann wrote:

Constant names for one thing, I thought?

Do you have any specific examples in mind I can look at to see what it shows. An idea of what you think it should show would also be useful.

During normal development, examples are a hundred times better than lots of prose, even if the synatx is from a (slightly) different language.

True. However, other plug-ins/scripts can be the best examples of the syntax and use of the "functions" listed in DB Browser. Also, leaving out language specific examples keeps the information more generic, avoids unneeded bloating of the files which comprise the GIMP, and mean a little less work for the people that need to translate all the information in to other spoken/written languages.

I won't make any changes related to DB Browser information until it is confirmed that changes are needed,

Personally, I don't think they are *necessary*, but I don't object them, either. Not that my objection or agreement should weigh very much(!).

Perhaps not so it may not need to be done for 2.0 but some changes could be made such as ensuring the names of constants are shown where only numeric values are currently given for certain arguments.

AFAICR, most if not all of the pdb interface is created from the .pdb files. At least the constant names, docs etc. are in there.

I got that impression when the ChangeLog indicated that a .pdb file was changed to removed the redundant code I recently reported in a .c file.

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 | -Pinkutus & the Borg