gimp and Adobe plugins (was Re: Fun projects?)

[dim owner]

Happy Thanksgiving!

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:
 http://partners.adobe.com/asn/tech/plugin/index.jsp
	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  
read.
	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 
advantages: 

: 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 
cents.


cheers,
RobC


--r
dorothy at oz:~> ls
scarecrow tinman lion
dorothy at oz:~> find . -name home
There's no place like home.