gimp and Adobe plugins (was Re: Fun projects?)
rtpc at comcast.net
Thu Nov 27 16:16:20 CST 2003
On Thursday 27 November 2003 00:10, you wrote:
> On November 26, 2003 04:31 pm, dim owner wrote:
> > So, a (the) big question is, how can we get this windows app to
> > compunicate with UNIX processes?
> Well, indeed, this is the $10000 question. I don't much care at this
> point wether Gimp can work with the Plugins or not, what I care about
> is to export their interface in a an ELF library so that Unix processes
> can call them. This is non-trivial, so the first question is:
> What is the Plugin interface?
Well! It would do this project no good if I were to break the agreement I
made with Adobe in regards these SDKs (I have the AE and Premiere ones too).
So, until I get a responce from Adobe or their maillist (I lost that
agreement), I won't directly provide any details from the SDK itself.
There's still plenty of information available online, though.
To answer your question, check out this link:
The PICA API document is still freely available, and is a pie-in-the-sky
review of plugin programming (containing none of the headers, etc, that one
needs to actually build a plugin, or investigate specifics). Section 2.3
describes the interface.
The actual prototype for the main entry point is not in this section (of
course, it is in the API guide in the SDK), but it is a pretty good and basic
You'll also want to review the gimp-pspi (v1.0.2) source... it's available at
Cinepaint's sourceforge downloads page, among other sites. The
/pspi-source-root/src/pspi.c has the struct for the entry point.
We certainly won't get 100% compatability: some/maybe many P$ filters call
other DLLs ... not just windows DLLs but their own ; possibly to extend their
functionality, but likely as a part of copy protection.
But the idea of implimenting the entirety of interaction between host and
plugin first seems a bad way to go about this (don't you think?). I would
suggest we build a minimal DLL that is interactive (returns ++integer), and
work on the UNIX end and Wine-dows host application from there. Afterwards,
we can come back and make the Adobe plugin host... this has some notable
: not quite so dramatically "non-trivial"
: we would have all the source code for both the host and the module
: we can modularize the interface, for different windows-linux interaction.
: this would allow us to 'pitch' a working prototype to other projects'
programmers (ie, we could get more resources to attack the problem)
Either way, is fine really ... I'll happily follow your lead. Just my 2
dorothy at oz:~> ls
scarecrow tinman lion
dorothy at oz:~> find . -name home
There's no place like home.
More information about the wine-devel