pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Re: interface builder queries

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

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

Re: [Pyobjc-dev] Re: breakage in CVS?

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

On Thursday, 28 August 2003, at 18:24, Zeph Campbell wrote:

>
>> Just van Rossum <ju...@le...> writes:
>>
>>> Michael Hudson wrote:
>>>
>>> It's AppKit.NSMakePoint()... But: why use it to begin with? NSPoints 
>>> are
>>> represented as 2-tuples.
>>
>> I can see that... I don't even want to use NSMakePoint, but being able
>> to import AppKit would be a bonus!
>
> As a noob to PyObjC, I had to find out the hard way what was and was 
> not included, and I guess the rule of thumb is that if it can be 
> expressed as a tuple, there's no reason to have a function just to 
> spit out the equivelent struct.
>
> BTW, the global function NSMakeRect wasn't included - sure it was 
> trivial to re-implement, but still...

NSMakeRect is included, it is in the current CVS tree (if you manage to 
get to that :-), and probably also in 1.0rc1.

Ronald

Re: [Pyobjc-dev] breakage in CVS?

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

Could you try installing after removing the existing PyObjC 
installation in site-packages. For some reason distutils sometimes 
doesn't install the new version of files.

Ronald

[Pyobjc-dev] Re: interface builder queries

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

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

[Pyobjc-dev] Re: breakage in CVS?

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

Zeph Campbell <ze...@ho...> writes:

>> Just van Rossum <ju...@le...> writes:
>>
>>> Michael Hudson wrote:
>>>
>>> It's AppKit.NSMakePoint()... But: why use it to begin with?
>>> NSPoints are
>>> represented as 2-tuples.
>>
>> I can see that... I don't even want to use NSMakePoint, but being able
>> to import AppKit would be a bonus!
>
> As a noob to PyObjC, I had to find out the hard way what was and was
> not included, and I guess the rule of thumb is that if it can be
> expressed as a tuple, there's no reason to have a function just to
> spit out the equivelent struct.

I seem to be causing some confusion here.

I do not care a jot whether NSMakePoint is defined in Foundation,
AppKit or not at all.

However, in the version of PyObjC I checked out today, when you import
AppKit, *AppKit/__init__.py* tries to import NSMakePoint and friends
from Foundation -- and fails.

I'm not asking for someone to help, I'm asking for someone to fix it!
Maybe Ronald missed a file in a check in?  That's what it looks like
to me.

Cheers,
mwh

-- 
  SPIDER:  'Scuse me. [scuttles off]
  ZAPHOD:  One huge spider.
    FORD:  Polite though.
                   -- The Hitch-Hikers Guide to the Galaxy, Episode 11

Re: [Pyobjc-dev] Re: breakage in CVS?

[Zeph C. <ze...@ho...>]

> Just van Rossum <ju...@le...> writes:
>
>> Michael Hudson wrote:
>>
>> It's AppKit.NSMakePoint()... But: why use it to begin with? NSPoints 
>> are
>> represented as 2-tuples.
>
> I can see that... I don't even want to use NSMakePoint, but being able
> to import AppKit would be a bonus!

As a noob to PyObjC, I had to find out the hard way what was and was 
not included, and I guess the rule of thumb is that if it can be 
expressed as a tuple, there's no reason to have a function just to spit 
out the equivelent struct.

BTW, the global function NSMakeRect wasn't included - sure it was 
trivial to re-implement, but still...

I guess that's why it's beta :-)

- Zeph

Re: [Pyobjc-dev] Re: breakage in CVS?

[Just v. R. <ju...@le...>]

Michael Hudson wrote:

> I can see that... I don't even want to use NSMakePoint, but being able
> to import AppKit would be a bonus!

*blush*

<hides-under-desk>

Just

[Pyobjc-dev] Re: interface builder queries

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

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

[Pyobjc-dev] [ pyobjc-Bugs-796738 ] problems in Modules/objc/class-list.m?

[SourceForge.net <no...@so...>]

Bugs item #796738, was opened at 2003-08-28 16:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=796738&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: problems in Modules/objc/class-list.m?

Initial Comment:
I eventually tracked my crashing IBPalette problems down to 

PyObjC_GetClassList.



I didn't understand the "if (neededLen >= 1024)" block of 

code, so I #if 0-ed it out and replaced it with something 

fairly mindless (see attached).



My IBPalette *still* doesn't work, but it doesn't make IB crap 

itself anymore...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=796738&group_id=14534

[Pyobjc-dev] Re: breakage in CVS?

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

Just van Rossum <ju...@le...> writes:

> Michael Hudson wrote:
>
>> I managed to trick SF into letting me update via anon CVS and this
>> happened:
>> 
>> Python 2.3+ (#1, Aug 28 2003, 14:14:54) 
>> [GCC 3.1 20020420 (prerelease)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>> ->> import AppKit
>> Traceback (most recent call last):
>>   File "<input>", line 2, in ?
>>   File 
>>
> "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-
> packages/PyObjC/AppKit/
>> __init__.py", line 32, in ?
>>     NSMakePoint = Foundation.NSMakePoint
>> AttributeError: 'module' object has no attribute 'NSMakePoint'
>
> It's AppKit.NSMakePoint()... But: why use it to begin with? NSPoints are
> represented as 2-tuples.

I can see that... I don't even want to use NSMakePoint, but being able
to import AppKit would be a bonus!

Cheers,
mwh

-- 
  #ifndef P_tmpdir
  printf( "Go buy a better computer" );
  exit( ETHESKYISFALLINGANDIWANTMYMAMA );
                         -- Dimitri Maziuk on writing secure code, asr

Re: [Pyobjc-dev] breakage in CVS?

[Just v. R. <ju...@le...>]

Michael Hudson wrote:

> I managed to trick SF into letting me update via anon CVS and this
> happened:
> 
> Python 2.3+ (#1, Aug 28 2003, 14:14:54) 
> [GCC 3.1 20020420 (prerelease)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> ->> import AppKit
> Traceback (most recent call last):
>   File "<input>", line 2, in ?
>   File 
>
"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-
packages/PyObjC/AppKit/
> __init__.py", line 32, in ?
>     NSMakePoint = Foundation.NSMakePoint
> AttributeError: 'module' object has no attribute 'NSMakePoint'

It's AppKit.NSMakePoint()... But: why use it to begin with? NSPoints are
represented as 2-tuples.

Just

[Pyobjc-dev] breakage in CVS?

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

I managed to trick SF into letting me update via anon CVS and this
happened:

Python 2.3+ (#1, Aug 28 2003, 14:14:54) 
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
->> import AppKit
Traceback (most recent call last):
  File "<input>", line 2, in ?
  File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PyObjC/AppKit/__init__.py", line 32, in ?
    NSMakePoint = Foundation.NSMakePoint
AttributeError: 'module' object has no attribute 'NSMakePoint'

Is it just me?

Cheers,
mwh

-- 
  LINTILLA:  You could take some evening classes.
    ARTHUR:  What, here?
  LINTILLA:  Yes, I've got a bottle of them.  Little pink ones.
                   -- The Hitch-Hikers Guide to the Galaxy, Episode 12

Re: [Pyobjc-dev] Re: interface builder queries

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

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

[Pyobjc-dev] Re: interface builder queries

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

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

Re: [Pyobjc-dev] Re: interface builder queries

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

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

Re: [Pyobjc-dev] Re: interface builder queries

[b.bum <bb...@ma...>]

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

[Pyobjc-dev] Re: interface builder queries

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

"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

[Pyobjc-dev] Re: interface builder queries

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

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

Re: [Pyobjc-dev] interface builder queries

[Just v. R. <ju...@le...>]

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

Re: [Pyobjc-dev] interface builder queries

[b.bum <bb...@ma...>]

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

Re: [Pyobjc-dev] interface builder queries

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

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

Re: [Pyobjc-dev] defaults.plist not making it into standardUserDefaults()?

[b.bum <bb...@ma...>]

Are you registering the defaults?  I.e.:

NSUserDefaults.standardUserDefaults().registerDefaults_(NSDictionary.dic 
tionaryWithContentsOfFile_(NSBundle.mainBundle().pathForResource_ofType_ 
("defaults", "plist")))

On Aug 25, 2003, at 7:41 AM, Zachery Bir wrote:

> The entries in my app's defaults.plist don't seem to be registering  
> when I try to access them from a dry-run with no existing plist file  
> in ~/Library/Preferences/

[Pyobjc-dev] interface builder queries

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

[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

[Pyobjc-dev] NSBrowserCell help

[Zeph C. <ze...@ho...>]

Now, I subclassed the NSBrowserCell class (MyBrowserCell), and in my 
awakeFromNib() I call:

self.mBrowser.setCellClass_(MyBrowserCell)

yet it does not set the cell class for the browser ("print 
self.mBrowser.cellClass()" confirms this)

I can't call setCellClass_(MyBrowserCell.class()) because the python 
interpreter chokes on the class keyword, and MyBrowserCell alone should 
return the same thing anyway.

I call "cell.__class__ = MyBrowserCell" in my 
browser_willDisplayCell_atRow_column_() implementation, but that just 
gets my past one error, and isn't a real fix

Help!

Thanks
- zeph

[Pyobjc-dev] defaults.plist not making it into standardUserDefaults()?

[Zachery B. <zb...@ur...>]

The entries in my app's defaults.plist don't seem to be registering 
when I try to access them from a dry-run with no existing plist file in 
~/Library/Preferences/

Should I need to explicitly call syncronize() in my init() method? I've 
tried calling resetStandardUserDefaults(), but it didn't seem to pull 
in the defaults.

Thanks,

Zac