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

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

Reply via email to