Thread: [Pyobjc-dev] interface builder queries
Brought to you by:
ronaldoussoren
Menu
▾
▴
pyobjc-dev
|
From: Michael H. <mw...@py...> - 2003-08-26 16:19:33
|
[this can hardly be the best place to ask this question...]
My learn-PyObjC project -- a resource editor for EV Nova -- is going
quite nicely, but I have a question or two:
1) I'm going to have a lot (20? 30?) of NIBs and each one will likely
have it's own controller class (this seems to be the standard
approach) and it would be convenient to have most of these inherit
from a custom class. I don't see how to teach IB about this one
custom class that is shared between all the NIB files in the
project. I suppose I could just add the functionality I want to
NSWindowController...
2) How hard is it to generate/manipulate NIBs programmatically?
They're mostly NSArchivered lumps of data, right? The point behind
this question is that I have a description of various data formats
and it might save time to generate a really clunky interface from
this description, and then turn it into a less clunky interface by
monkeying about in IB (but not have to sort *all* those connections
out by hand).
In general, the more I play with PyObjC, the more impressed I get.
Nice work!
Cheers,
mwh
--
It is never worth a first class man's time to express a majority
opinion. By definition, there are plenty of others to do that.
-- G. H. Hardy
|
|
From: Ronald O. <ous...@ci...> - 2003-08-26 16:29:10
|
On dinsdag, 26 augustus 2003, at 18:19PM, Michael Hudson wrote: > [this can hardly be the best place to ask this question...] > > My learn-PyObjC project -- a resource editor for EV Nova -- is going > quite nicely, but I have a question or two: > > 1) I'm going to have a lot (20? 30?) of NIBs and each one will likely > have it's own controller class (this seems to be the standard > approach) and it would be convenient to have most of these inherit > from a custom class. I don't see how to teach IB about this one > custom class that is shared between all the NIB files in the > project. I suppose I could just add the functionality I want to > NSWindowController... You can define the base-class in every NIB file, only add the actions/outlets you'll actually use. IIRC NibClassBuilder will automaticly merge the class definitions in the NIB files (as long as they all have the same super class). The definition in the NIB is just a promise that you'll provide a class in your code. > > 2) How hard is it to generate/manipulate NIBs programmatically? > They're mostly NSArchivered lumps of data, right? The point behind > this question is that I have a description of various data formats > and it might save time to generate a really clunky interface from > this description, and then turn it into a less clunky interface by > monkeying about in IB (but not have to sort *all* those connections > out by hand). I don't know, but I'd like to know. Please tell us if you find out :-) Ronald |
|
From: b.bum <bb...@ma...> - 2003-08-26 16:51:12
|
On Aug 26, 2003, at 9:28 AM, Ronald Oussoren wrote: >> 2) How hard is it to generate/manipulate NIBs programmatically? >> They're mostly NSArchivered lumps of data, right? The point behind >> this question is that I have a description of various data formats >> and it might save time to generate a really clunky interface from >> this description, and then turn it into a less clunky interface by >> monkeying about in IB (but not have to sort *all* those connections >> out by hand). > > I don't know, but I'd like to know. Please tell us if you find out :-) Given that you want to do the manipulation with a goal of writing out a NIB file that can subsequently be monkeyed about with in IB, you will be nicely surprised. Look in the InterfaceBuilder.framework. API is provided for making/breaking connections and otherwise manipulating the object graph found within a NIB file. It should provide most/all of the features you need. I would suggest writing an InterfaceBuilder Palette (using PyObjC, of course -- but you'll need a framework build of Python) that contains the tools needed to modify the object graph of your NIB files (or produce the object graph). Point of reference: about a year ago, I helped a company port their NeXTSTEP 3.3 code and interface files forward to OS X. We used OpenStep 4.2 as a go-between for NIB conversion and, as a result, were able to convert-- including object graph manipulation-- all 100+ NIB files (20,000+ custom objects across the NIBs) from NS 3.3 to OS X. This also required re-arranging views and changing object configurations to help convert the NS 3.3 look-n-feel to OS X. There are some gotchas and tricks, but it does work and works very well.... b.bum |
|
From: Michael H. <mw...@py...> - 2003-08-26 18:28:20
|
"b.bum" <bb...@ma...> writes: > On Aug 26, 2003, at 9:28 AM, Ronald Oussoren wrote: >>> 2) How hard is it to generate/manipulate NIBs programmatically? >>> They're mostly NSArchivered lumps of data, right? The point behind >>> this question is that I have a description of various data formats >>> and it might save time to generate a really clunky interface from >>> this description, and then turn it into a less clunky interface by >>> monkeying about in IB (but not have to sort *all* those connections >>> out by hand). >> >> I don't know, but I'd like to know. Please tell us if you find out :-) > > Given that you want to do the manipulation with a goal of writing out > a NIB file that can subsequently be monkeyed about with in IB, you > will be nicely surprised. With Cocoa, I've come to expect to be :-) > Look in the InterfaceBuilder.framework. API is provided for > making/breaking connections and otherwise manipulating the object > graph found within a NIB file. It should provide most/all of the > features you need. Somehow I managed to miss that. Duh! > I would suggest writing an InterfaceBuilder Palette (using PyObjC, of > course -- but you'll need a framework build of Python) that contains > the tools needed to modify the object graph of your NIB files (or > produce the object graph). I had stumbled towards the fact that I might want to do that, but I have *no* idea where to even start... I don't suppse anyone has an example knocking around? Even one in ObjC would be helpful, I guess. Cheers, mwh -- : exploding like a turd Never had that happen to me, I have to admit. They do that often in your world? -- Eric The Read & Dave Brown, asr |
|
From: b.bum <bb...@ma...> - 2003-08-26 21:04:23
|
On Aug 26, 2003, at 10:19 AM, Michael Hudson wrote: > I had stumbled towards the fact that I might want to do that, but I > have *no* idea where to even start... I don't suppse anyone has an > example knocking around? Even one in ObjC would be helpful, I guess. - have a look at the example palette(s) provided in /Developer/Examples/ - create an Interface Builder palette project (punt on the whole PyObjC thing for the moment -- straight ObjC will be more straightforward for now) You can listen for the following notifications if you want to know about Documents being opened/saved/closed: IB_EXTERN NSString * const IBDidOpenDocumentNotification; IB_EXTERN NSString * const IBWillSaveDocumentNotification; IB_EXTERN NSString * const IBDidSaveDocumentNotification; IB_EXTERN NSString * const IBWillCloseDocumentNotification; The IBDocuments protocol contains most of what you need for attaching and detaching objects. I would suggest that you use nibtool to dump a summary of the nib file at command line... nibtool -a MyTest.nib .... then exercise the APIs found in the InterfaceBuilder framework to see how the programatically interrogated object graph matches the summary from nibtool. b.bum |
|
From: Ronald O. <ous...@ci...> - 2003-08-26 21:20:56
|
On dinsdag, 26 augustus 2003, at 23:04PM, b.bum wrote: > On Aug 26, 2003, at 10:19 AM, Michael Hudson wrote: >> I had stumbled towards the fact that I might want to do that, but I >> have *no* idea where to even start... I don't suppse anyone has an >> example knocking around? Even one in ObjC would be helpful, I guess. > > - have a look at the example palette(s) provided in > /Developer/Examples/ > > - create an Interface Builder palette project (punt on the whole > PyObjC thing for the moment -- straight ObjC will be more > straightforward for now) Python should also work, as long as IB is single threaded, see the EnvironmentPrefs example for a python based plugin. That's a plugin for System Preferences, but the mechanics should be simular for IB pallettes. The hard part is the complete lack of documentation for writing IB pallettes ;-) Ronald |
|
From: Michael H. <mw...@py...> - 2003-08-27 18:06:08
|
Ronald Oussoren <ous...@ci...> writes:
> On dinsdag, 26 augustus 2003, at 23:04PM, b.bum wrote:
>
>> On Aug 26, 2003, at 10:19 AM, Michael Hudson wrote:
>>> I had stumbled towards the fact that I might want to do that, but I
>>> have *no* idea where to even start... I don't suppse anyone has an
>>> example knocking around? Even one in ObjC would be helpful, I guess.
>>
>> - have a look at the example palette(s) provided in
>> /Developer/Examples/
>>
>> - create an Interface Builder palette project (punt on the whole
>> PyObjC thing for the moment -- straight ObjC will be more
>> straightforward for now)
> Python should also work, as long as IB is single threaded, see the
> EnvironmentPrefs example for a python based plugin. That's a plugin
> for System Preferences, but the mechanics should be simular for IB
> pallettes.
Right, I'll see if I can blend an IBPalette example with the PyObjC
screensaver example. I'll try to package it up for the Examples/
directory if I come up with anything useful.
> The hard part is the complete lack of documentation for writing IB
> pallettes ;-)
Yeah, I'd kind of noticed that. Time to learn to read Objective C
examples, I guess.
I can already tell that debugging these suckers is going to be "fun".
Cheers,
mwh
--
In the 1950s and 60s there was a regular brain drain of young
Australians from the cities to London, but it was because of
money, culture and opportunity, not spiders.
-- Al Grant, ucam.chat, from Owen Dunn's review of the year
|
|
From: Michael H. <mw...@py...> - 2003-08-28 16:10:09
|
Michael Hudson <mw...@py...> writes: >> Python should also work, as long as IB is single threaded, see the >> EnvironmentPrefs example for a python based plugin. That's a plugin >> for System Preferences, but the mechanics should be simular for IB >> pallettes. > > Right, I'll see if I can blend an IBPalette example with the PyObjC > screensaver example. I'll try to package it up for the Examples/ > directory if I come up with anything useful. Well, after fixing what I think to be a couple of bugs in PyObjC, I've run into another problem. I think. It seems interface builder uses [NSBundle classNamed:] to find the palette class, and my Python classes aren't showing up to this function (it shows up as the result to [NSBundle principalClass], though). It may or may not be coincidental that when I register an observer for NSBundleDidLoadNotification I never see my Python classes go by... I'm way out of my depth here. Cheers, mwh -- Of the four project development variables - scope, cost, time and quality - quality isn't really a free variable. The only possible values are "excellent" and "insanely excellent", depending on whether lives are at stake. -- Kent Beck, XP Explained |
|
From: Michael H. <mw...@py...> - 2003-08-29 09:51:20
|
Michael Hudson <mw...@py...> writes:
> Michael Hudson <mw...@py...> writes:
>
>>> Python should also work, as long as IB is single threaded, see the
>>> EnvironmentPrefs example for a python based plugin. That's a plugin
>>> for System Preferences, but the mechanics should be simular for IB
>>> pallettes.
>>
>> Right, I'll see if I can blend an IBPalette example with the PyObjC
>> screensaver example. I'll try to package it up for the Examples/
>> directory if I come up with anything useful.
>
> Well, after fixing what I think to be a couple of bugs in PyObjC, I've
> run into another problem. I think.
>
> It seems interface builder uses [NSBundle classNamed:] to find the
> palette class, and my Python classes aren't showing up to this
> function (it shows up as the result to [NSBundle principalClass],
> though).
This would seem to be because the objc runtime thinks that Python
classes are not dynamically loaded (fair enough, but it makes the task
at hand fairly tricky).
It is odd that you have
NSBundle.bundleForClass(aBundle.principalClass()) != aBundle
though.
Still way over my depth,
mwh
--
If i don't understand lisp, it would be wise to not bray about
how lisp is stupid or otherwise criticize, because my stupidity
would be archived and open for all in the know to see.
-- Xah, comp.lang.lisp
|
|
From: Ronald O. <ous...@ci...> - 2003-08-29 10:22:30
|
On vrijdag, 29 augustus 2003, at 11:51AM, Michael Hudson wrote: > Michael Hudson <mw...@py...> writes: > >> Michael Hudson <mw...@py...> writes: >> >>>> Python should also work, as long as IB is single threaded, see the >>>> EnvironmentPrefs example for a python based plugin. That's a plugin >>>> for System Preferences, but the mechanics should be simular for IB >>>> pallettes. >>> >>> Right, I'll see if I can blend an IBPalette example with the PyObjC >>> screensaver example. I'll try to package it up for the Examples/ >>> directory if I come up with anything useful. >> >> Well, after fixing what I think to be a couple of bugs in PyObjC, I've >> run into another problem. I think. >> >> It seems interface builder uses [NSBundle classNamed:] to find the >> palette class, and my Python classes aren't showing up to this >> function (it shows up as the result to [NSBundle principalClass], >> though). > > This would seem to be because the objc runtime thinks that Python > classes are not dynamically loaded (fair enough, but it makes the task > at hand fairly tricky). > > It is odd that you have > > NSBundle.bundleForClass(aBundle.principalClass()) != aBundle > > though. > > Still way over my depth, Welcome to the club :-) 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. BTW. I added some code to make it safe to call from Objective-C to python from any thread, including those without a Python threadstate, using the API defined in PEP311. The bad news is that I did this in a tree that contains Panther specific code ;-(. Ronald |
|
From: Michael H. <mw...@py...> - 2003-08-29 11:50:50
|
Ronald Oussoren <ous...@ci...> writes:
> On vrijdag, 29 augustus 2003, at 11:51AM, Michael Hudson wrote:
>
>> Michael Hudson <mw...@py...> writes:
>>
>>> Michael Hudson <mw...@py...> writes:
>>>
>>>>> Python should also work, as long as IB is single threaded, see the
>>>>> EnvironmentPrefs example for a python based plugin. That's a plugin
>>>>> for System Preferences, but the mechanics should be simular for IB
>>>>> pallettes.
>>>>
>>>> Right, I'll see if I can blend an IBPalette example with the PyObjC
>>>> screensaver example. I'll try to package it up for the Examples/
>>>> directory if I come up with anything useful.
>>>
>>> Well, after fixing what I think to be a couple of bugs in PyObjC, I've
>>> run into another problem. I think.
>>>
>>> It seems interface builder uses [NSBundle classNamed:] to find the
>>> palette class, and my Python classes aren't showing up to this
>>> function (it shows up as the result to [NSBundle principalClass],
>>> though).
>>
>> This would seem to be because the objc runtime thinks that Python
>> classes are not dynamically loaded (fair enough, but it makes the task
>> at hand fairly tricky).
>>
>> It is odd that you have
>>
>> NSBundle.bundleForClass(aBundle.principalClass()) != aBundle
>>
>> though.
>>
>> Still way over my depth,
>
> Welcome to the club :-)
:-)
> 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...
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.
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).
> BTW. I added some code to make it safe to call from Objective-C to
> python from any thread, including those without a Python threadstate,
> using the API defined in PEP311. The bad news is that I did this in a
> tree that contains Panther specific code ;-(.
The threadedness of IB doesn't seem to have caused any problems yet
(unless that turns out to be responsible for the crashes I saw in
PyObjC_GetClassList).
Cheers,
mwh
--
at any rate, I'm satisfied that not only do they know which end of
the pointy thing to hold, but where to poke it for maximum effect.
-- Eric The Read, asr, on google.com
|
|
From: Ronald O. <ous...@ci...> - 2003-08-29 12:10:55
|
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. > > 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. > > 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. 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). 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 :-(. Ronald |
|
From: Ronald O. <ous...@ci...> - 2003-08-29 13:09:10
Attachments:
pluginbuilder.py
|
On Friday, 29 August 2003, at 14:10, Ronald Oussoren wrote:
>
> 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).
>
>
that works al right.
If you use the attached pluginbuilder.py and add the following code to
init_objc in Modules/objc/module.m you can build a IB.palette that
actually loads. I haven't checked if you can actually do anything in
the plugin.
/* Python based plugin bundles currently use only
PyObjClass_GetClass,
* add that seperately to avoid distributing pyobjc-api.h for
now
*/
{
PyObject* v =
PyCObject_FromVoidPtr((void*)(PyObjCClass_GetClass), NULL);
if (v == NULL) return;
PyDict_SetItemString(d, "__C_GETCLASS__", v);
}
Warning: this is a hack and I don't know yet if I want to see this code
anywhere near our repository.
Ronald
|
|
From: Michael H. <mw...@py...> - 2003-08-28 12:37:31
|
On Tuesday, Aug 26, 2003, at 22:20 Europe/London, Ronald Oussoren wrote:
>
> On dinsdag, 26 augustus 2003, at 23:04PM, b.bum wrote:
>
>> On Aug 26, 2003, at 10:19 AM, Michael Hudson wrote:
>>> I had stumbled towards the fact that I might want to do that, but I
>>> have *no* idea where to even start... I don't suppse anyone has an
>>> example knocking around? Even one in ObjC would be helpful, I guess.
>>
>> - have a look at the example palette(s) provided in
>> /Developer/Examples/
>>
>> - create an Interface Builder palette project (punt on the whole
>> PyObjC thing for the moment -- straight ObjC will be more
>> straightforward for now)
> Python should also work, as long as IB is single threaded,
^^^^^^
This might be a problem. After some idiocies on my part (and finding
that palettes refer to some things in the Info.plist file, but
generally seem to find a "palette.table" file more significant),
loading my palette into IB crashes it, like so:
Date/Time: 2003-08-28 00:19:28 +0100
OS Version: 10.2.6 (Build 6L60)
Host: Michael-Hudsons-Computer.local.
Command: Interface Builder
PID: 2359
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xffffb918
Thread 0 Crashed:
#0 0xa0d4a538 in characterSet.0
#1 0xa0d4a538 in characterSet.0
Thread 1:
#0 0x90014c68 in syscall_thread_switch
#1 0x97e03ef4 in +[NSThread sleepUntilDate:]
#2 0x93081cac in -[NSUIHeartBeat _heartBeatThread:]
#3 0x97e2cc50 in forkThreadForFunction
#4 0x90020c88 in _pthread_body
PPC Thread State:
srr0: 0xa0d4a538 srr1: 0x0000f030 vrsave: 0x00000000
xer: 0x00000000 lr: 0xa0d4a538 ctr: 0x9005e258 mq: 0x00000000
r0: 0x020522a0 r1: 0xbfffa9e0 r2: 0x4804424b r3: 0x01f9d890
r4: 0x00000000 r5: 0x0000012e r6: 0xbfff98e4 r7: 0xa1b1c1d3
r8: 0x0012c010 r9: 0xa30a0978 r10: 0x01f8a010 r11: 0xa0d4a538
r12: 0x9005e258 r13: 0x0149275c r14: 0x01fd00f0 r15: 0x1010278c
r16: 0x00000000 r17: 0x00000000 r18: 0x10072ae8 r19: 0x0206b9f4
r20: 0x00000000 r21: 0x1007278c r22: 0x015d6f60 r23: 0x0206b9f4
r24: 0x100f3624 r25: 0xa7e04ef4 r26: 0xa30a1d28 r27: 0xa7e02c14
r28: 0xa309d8e8 r29: 0xa309e278 r30: 0xa30a0d08 r31: 0xa7e030f4
I think thread 0 could technically be described as being in
'never-never land'. Control is making it to Python, FWIW, it's just
dying horribly on the import of AppKit (or Foundation or PyObjCTools
but not, say, sys or time or objc).
This is the point where running away terribly fast starts to look a
good option. Doing any significant digging will require my own
framework build of Python and my own build of PyObjC, things which take
a little while to acquire on this iBook... (hey, Jack, what about an
"install source" option to PackMan <wink>?).
Cheers,
mwh
|
|
From: Just v. R. <ju...@le...> - 2003-08-26 18:00:57
|
Ronald Oussoren wrote: > IIRC NibClassBuilder will automaticly merge the class definitions in > the NIB files (as long as they all have the same super class). You Recall Correctly. > > 2) How hard is it to generate/manipulate NIBs programmatically? > > They're mostly NSArchivered lumps of data, right? The point behind > > this question is that I have a description of various data formats > > and it might save time to generate a really clunky interface from > > this description, and then turn it into a less clunky interface by > > monkeying about in IB (but not have to sort *all* those connections > > out by hand). It would depend on the amount of monkeying around you plan to do, but maybe it's an option to create those bits of the interface in code. It's not pretty, but not _that_ hard either. Just |
|
From: Michael H. <mw...@py...> - 2003-08-26 18:09:46
|
Just van Rossum <ju...@le...> writes:
>> > 2) How hard is it to generate/manipulate NIBs programmatically?
>> > They're mostly NSArchivered lumps of data, right? The point behind
>> > this question is that I have a description of various data formats
>> > and it might save time to generate a really clunky interface from
>> > this description, and then turn it into a less clunky interface by
>> > monkeying about in IB (but not have to sort *all* those connections
>> > out by hand).
>
> It would depend on the amount of monkeying around you plan to do, but
> maybe it's an option to create those bits of the interface in code.
That would be missing the point of what I want to acheive: I want to
do things like group controls into NSTabViews & edit some text. Yes,
I could do this in code, but I'm not going to :-)
> It's not pretty, but not _that_ hard either.
Nor is it really important, certainly not important enough to endure
this level of unprettyness...
Cheers,
mwh
--
FORD: Just pust the fish in your ear, come on, it's only a
little one.
ARTHUR: Uuuuuuuuggh!
-- The Hitch-Hikers Guide to the Galaxy, Episode 1
|
|
From: Michael H. <mw...@py...> - 2003-08-29 12:23:30
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X