Re: [Pyobjc-dev] Embedding in Apps & Loading preferences Bundles

[Ronald O. <ous...@ci...>]

On Monday, Nov 25, 2002, at 14:37 Europe/Amsterdam, bb...@ma... wrote:

> On Monday, November 25, 2002, at 08:02 AM, Ronald Oussoren wrote:
>> Some time in the future I will probably try to write whatever is 
>> needed to get prefpanes to work. That is probably simular to what is 
>> needed to write plugins for programs that use Objective-C classes as 
>> plugins (e.g. which is basicly what the system preferences 
>> application is doing). I probably won't work on forcing this onto 
>> unwilling applications.
>
> I.e. implement an application that implements enough of the various 
> classes in Python that are required to make a loaded preferences panel 
> work in some place other than System Preferences?  Or create a plugin 
> type architecture for new apps?

The former, mostly because it would be a neat trick but adding a System 
Preference is IMHO better than adding lots of small applications when 
you want to write 'customize-some-unix-tool' applications.

>
> Key challenge:   The classes that are subsequently subclassed by the 
> loaded module must have instance variables that look/feel/act exactly 
> like the iVars in the original parent class....

That should be no problem, PyObjC can already to that. For me the key 
challenge is finding a way to initialize an embedded python interpreter 
and run a python script when the plugin bundle is loaded (and for bonus 
points: Initialize exactly 1 interpreter, even when loading more than 1 
python-based plugin)

>
>> Finding a way to automaticly execute a function when 'our' shared 
>> library is loaded will probably the most problematic part of this. 
>> That is: Whenever the 'pyobjcextension' shared libary is loaded 
>> 'initPyObjCExtension' in that library should run. I haven't looked 
>> into this yet and this may well be either trivial or impossible.
>
> Assuming that the target application is ObjC, simply creating a 
> +(void)load in a class/category within the dylib should be enough to 
> cause a hunk of code to be executing that can call 
> -initPyObjCExtension.   There is also a similar mechanism in the pure 
> C++ world.

I hadn't though of using a (dummy) class to do this. Thanks for the tip.

Ronald