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(a)oz:~> ls scarecrow tinman lion dorothy(a)oz:~> find . -name home There's no place like home.