How to make plugin resident on Mac OS?

[Guest]

Does anyone have a way to do this? It has to work for both automate and filter plugins.

I've tried the following:

1. Persistent property in PiPl. This works for automate plugins in CS3, but not CS2. It doesn't seem to work for filter plugins.

2. Call SPAccess AcquirePlugin() on own plugin ref. This is documented to work but always returns !Acq. This is weird because GetPluginAccess() works fine (but doesn't bump the reference count.)

3. Use SPPlugins to hunt through list returned by GetRuntimePluginList() so I can have one of my plugins find the other and load it and vice versa. My plugins are not in this list. In fact it's almost empty.

4. Try using CFBundle functions to keep the executable loaded. Doesn't work.

[bernd2007]

Did you have any luck with this?

I'm running into the same problem right now. I have an automation and a filter plugin in the same plugin bundle, and Photoshop happily decides to unload the bundle as soon as a call to the filter plugin has finished, leading to an immediate and very bad crash that was awfully hard to debug in the first place.

I'm still reluctant to split my code into two bundles, because of all the extra work that comes with it.

[Guest]

Sorry, no, I had no luck. My plug-ins were already in separate bundles though so I didn't have to do what you're going to have to do. I only had to make sure my filter had access to the persistent information it needed which I did by exporting a 'suite' of functions from my automate plugin and having the filter pick them up. Note that I couldn''t use SPSuites for this as it seems to be entirely broken in Photoshop. I had to store a pointer to my exported suite in the registry 😞

If you want to keep all your business code in a single executable I think the best solution would be to build it as a separate shared library and have both automate and filter plug-ins link against that. Photoshop won't know about this shared library so you'll be able to rely on the standard OS mechanisms for DLLs/dylibs. It should then be straightforward to maintain a persistent reference to the shared library to stop it unloading when Photoshop unloads your plug-in(s). You'd already have that if your automate plug-in (now just a shell) is in a separate bundle which can be truly persistent. Or you might have the shared library maintain a reference to itself.

[bernd2007]

I worked around the problem similarly to option 2), but on the OS level. On Mac OS X I use my own set of dlopen/dlclose calls on my own plugin, to make sure its reference count doesn't reach zero and is unloaded early. On Windows this never happened to me in the first place.

[ilvar]

Interesting! We worked around the issue with an assmebler hack... and yes, the problem was indeed MacOS X specific.

[Rahul Kathet]

hi i need one help, can i edit photoshop default tool like brush, if i want to make sound on it is that is possible?

[Chris Cox]

Um, what does that have to do with the topic at hand?

[ilvar]

1) Persistent PIPL property does work fine for automation on CS2-CS4. It doesn't help with filters, that's true, however is it reaally necessary to keep the filter loaded? If this is what really want, I'm afraid nothing short of low level hack can help you.

3) I believe GetRuntimePluginList() is broken, for at least last N versions

[Guest]

1) How about it's in the same bundle as an automate plugin and you want to keep the automate plugin loaded? It was mentioned by a previous poster that the bundle gets unloaded when the filter exits, even though the automate plugin is supposed to be persistent. I don't have this situation myself but if it's true then it sounds like a bad bug in Photoshop.

2) What happened to 2)?

3) ISTM a whole bunch of stuff that is included in the official SDK is similarly broken.

[ilvar]

1) This indeed was the case when we last tested bundled automation/filter: unloading filter also unloads the automation regardless of its persistent PIPL property. As I've said in the previous post, to the best of my knowledge only dirty low-level hooks can prevent this from happening. As this is certainly not the most maintainable or safe way of doing it, if you can structure your plugin so that you don't have to go through this pain and risk having it broken in each new release, I'd certainly suggest so. This whole problem, btw, was introduced only either in CS3 or CS4 and wans't present in older releases.

2) I have a de ja vue about trying this approach, but as I don't remember the result it probably didn't help. This being said, we researched it sometime circa CS or CS2 and things do tend to change from version to version.

3) Well, all what's left for us to do is to keep filing bug reports in each beta cycle, hoping that one day Adobe gods will smile at us and all what's broken will magically get fixed... On the other hand, I cannot really second your claim that sSPSuites is "entirely broken" - it actually does work well for us: we can publish suites and successfully communicate between plugins.