On Tue, Aug 07, 2001 at 05:28:15PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote:
> 3) Changes to the plug-in API
>
> The File->Open dialog would behave as follows: if the given path leads
> to a regular file, open it as usual (no extra path). If the path does
A loong time ago I hacked the gimp to allow a variable number of arguments
in pdb calls - if the code still works then it's already possible to call
functions with a variable number of arguments.
Each plug-in gets the actual number of arguments so it's a matter of checking
it to see wether an extra argument exists.
> In order to support this, the file_load/save API has to be changed by
extended, only, even ;)
> file is edited. The only thing that would have to change in the
> current plug-ins is the addition of this parameter that would be
> ignored.
Even if we didn't have variable-number-of-args, the gimp itself knows how
many agruments a plug-in takes and could act accordingly, i.e. by not passing
in more argument than neccessary.
> 4) Feedback
>
> Any comments?
I just looked at gif.c, it does this:
if (nparams != 9)
in the noninteractive case, which nobody cares about and leaves the
interactive case untouched (i.e. it doesn't check). The same is true for
pnm.c.
I only expect problems with the non-optimal plug-in load/save data api
or maybe something obvious that I miss, but it would be sensible to call
plug-ins interactively with other arguments (or specially pre-populated
agruments) than in the interactive case - the api already allows all this,
I think.
The noninteractive part is much more difficult (in that it requires
sourcecode changes), but we could actually use the argument names (this is
off-topic). This might sound ugly in C, but most scripting languages (e.g.
perl) actually have functions which accept many arguments. The key is not
to use them but default them sensibly:
new Coro::Socket PeerHost => "gimp.org", PeerPort => 80;
and the many other arguments get sensible default values (like Multihomed
=> 1).
In the long run, we need to use this approach anyway (think all the nice
gimp functions with waaay to many arguments).
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer