[Pyobjc-dev] Re: interface builder queries

[Michael H. <mw...@py...>]

Ronald Oussoren <ous...@ci...> writes:

> On Friday, 29 August 2003, at 13:51, Michael Hudson wrote:
>
>>> Thanks for reminding me of this issue. I had noticed this when
>>> building the preference panes, but didn't think this was very
>>> important at the time. I'll see what I can do about this, this may be
>>> a hard problem.
>>
>> It looks it.  There's this intriguingly named function
>> _NSBundleAddClassesAndNotify, but I don't think you're expected to
>> call it...
>
> Hmm, I hadn't looked at global functions yet. The private methods
> didn't look interesting.

I only found that one by accident in gdb :-)

>> Also, the feeling I get is that there's lot of hacking done to get
>> this sort of thing to work from Java, and it would probably take
>> someone from Apple to do the same for Python.  That may be too
>> pessimistic, though.
>
> We probably need support from Apple to get this to work reliably, I
> haven't found a documented API to register our classes.

Right.  Is cocoa-dev the place to ask?  (Although I susbscribed a few
days ago and the list seems to be mainly inhabited by people who can't
read documentation).

>> The nicest answer would be arrange for our bundle to load itself into
>> some subclass of NSBundle, but that doesn't look possible (and Mach-O
>> bundles don't even seem to have init sections, which rules out one
>> scary hack that occurred to me).
>
> They seem to have init sections, and you can use the +load method of
> classes as well. I use the latter to bootstrap Python based bundles,
> because I can get at the current bundle that way, which is handy for
> locating resources such as the python code.

Yeah, I've read & been playing with that code.

> My current idea for a hack to implement this is to dynamicly replace
> the 'isa' pointer of Python based bundles from that +load method. As
> longs as IB uses [bundle classNamed:] we would get a working
> situtation (although using an extremely ugly hack).

I actually tried this this morning :-) (probably not in an optimal
manner, but hey).

The problem is, I think, that IB does this:

bundle = [NSBundle bundleWithPath:...]
cls = [bundle classNamed:...]

NSBundle being the way it is, the loading of executable code (and
hence the executing of +[PyObjC_Bundle_SimpleIBPalette load]) happens
*inside* the call to -[NSBundle classNamed:].  So the 'isa' hacks are
too late.

Certainly, setting a breakpoint in gdb on
+[PyObjC_Bundle_SimpleIBPalette load] shows -[NSBundle classNamed:] in
+the backtrace.

> This seems to be the week for ugly hacks, I'm working on a full-screen
> application (using PyObjC of course) that uses pop-up buttons. Those
> don't work in full-screen mode, the pop-up menu seems to be behind my
> full-screen window. I've already filed a bug after someone else
> noticed he hadn't had any luck getting this to work and just avoids
> pop-up buttons. I haven't found a way to hack around this limitation
> :-(.

I saw your note to cocoa-dev about that...

Cheers,
mwh

-- 
  Not only does the English Language borrow words from other
  languages, it sometimes chases them down dark alleys, hits
  them over the head, and goes through their pockets.   -- Eddy Peters