On Fri, Jan 30, 2004 at 02:19:56PM -0500, Kevin Cozens <kcozens@xxxxxxxxxxxx> wrote:
> regardless of plug-in language. On the other hand, if you want to create
> a new image using an indexed palette its easier to remember to use
> GIMP_INDEXED_IMAGE rather than 4 or was that INDEXED_IMAGE, or
> INDEXED-IMAGE?
In perl, INDEXED-IMAGE needs to be quoted rather unnaturally
(&{'INDEXED-IMAGE'}), so perl users won't bother thinking about
this. Also, perl, unlike C, has mostly working namespaces, so prefixing
each and everything with an application/module name like GIMP_ is not
necessary.
Things are similar for script-fu (there are no namespace issues in
script-fu because it's self-contained and _ looks rather unnatural, I
think).
If somebody wants to write a plug-in in perl who only ever had written
plug-ins in C will have to think twice (at least), there is no doubt.
But a user having used perl before will look at some existing script
anyways (nobody writes plug-ins from scratch).
Think about the GIMP_ prefix as C's way to handle namespaces. As such,
it's part of the C calling convention only. This is handled different in
perl (Gimp::INDEXED_IMAGE or just INDEXED_IMAGE) and script-fu (script-fu
does not have a module or library concept to my knowledge, the the problem
of namespaces does not apply).
> What type of plug-in am I writing again? :-) You get the idea.
Frankly, people forgetting which type of plug-in (in which language) they
are currently writing need professional help *g*.
I am rather convinced that the number of people who can't remember that
they are currently writing C as opposed to scheme is rather low compared
to people that are aware of this.
> DB Browser. People are told to use the DB Browser information and yet,
> it provides misleading information that could frustrate the budding new
> script writer out there.
The DB Browser information should be consistent (i.e. for C _or_
scheme). The information in the DB Browser will never apply to perl
(python...) unless it would have a "perl mode", as perl simply is a
different language with different calling conventions.
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.
> And finally, on line 263 of plug-ins/script-fu/siod-wrapper.c is a
> comment which reads:
> These are for backwards compatibility; they should be removed sometime
>
> It appears in the end that I have merely finished something that was
Cleaning up things by removing cruft like this is very useful, and often
being overlooked. Thanks for doing this :=>
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.
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)
Which is close to actual perl, and should give developers the right
idea. It should convert constant names to perl form, too (it currently
doesn't, AFAICR). Having this info in the DB Browser might be useful, but
making the interface support all languages is quite difficult.
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. In the case of perl,
these rules are stated in the Gimp manpage, which is a must-read if you
want to develop plug-ins from scratch.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
