[GEM-dev] Re: [GEM-cvs] Gem/src/Pixes pix_freeframe.cpp,1.8,1.9

[james tittle]

On Feb 13, 2006, at 4:38 AM, IOhannes m zmoelnig wrote:
> after a quick glance at Pete's CoreImage plugins (i guess you are
> referring to those):
> how about trying to search for a file within the bundle?
> i see that the bundle for the plugin "Gloom" is a directory
> "CIGloom.frf" which holds the actual binary "CIGloom.frf/CIGloom"
> so my idea is to open_via_path() a file printf("%s.frf/%s", name,  
> name),
>  and pass that (probably stripping off the "/*" part) to bundle- 
> loader.
>
> however, i have no idea whether this is generic enough to keep  
> working...

...no, I think you've got a good idea:  the bundle is just a generic  
wrapper around a binary and some extra resources, so it will have the  
same typical structure for all the plugins...so we'll just have to  
add that extra bit of location info, specifically:

nameOfPlugin.frf/Versions/A/nameOfPlugin

...alternatively, there's a symlink to the binary at the first level  
(ie. "nameOfPlugin.frf/nameOfPlugi"), but I don't know how  
open_via_path() would deal with that...?

> the other question is, why freeframe-plugins on osx _are_ bundles  
> at all
> (i don't find this in the specs)

...yeh, it's pretty clear from the top of the spec that they're to  
be .so's (or .dylib's in the mac-world), and that's what it used to  
be:  it's not clear, and I have yet to find any discussion of it  
being changed...seems to've happened offlist sometime...

...anyway, one advantage of the bundle structure is that it allows  
for inclusion of extra resources, like say an icon for an fx button,  
or a splashscreen, or ...?

thanx,
jamie

btw:  I'm working on finishing the "round-trip" altivec  
accellerations for colorspace conversions...then I'd say we're ok for  
looking at release...are you interested (or anyone?) in doing these  
conversions in mmx/sse/sse2?