pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] NIB Validation & action methods

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

bb...@ma... wrote:

> For action methods, I would suggest not building the stub methods for 
> each action.   Cocoa's nib loading mechanism already verifies that an 
> action method exists as the NIB is loaded and, if not, will emit a 
> message such as...
> 
> 2002-11-16 16:29:47.283 example[1603] Could not connect the action 
> randomAction: to target of class ExampleObject
> 
> .... which serves nicely to remind the developer that that particular 
> action method needs to be implemented.   Note that pushing the button 
> that tried to connect that action doesn't do anything.

Erm, when is this warning emitted? When the class is instantiated or when the
button is clicked? If the latter: NibLoader could do it at class-build-time.

Just

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

On Saturday, November 16, 2002, at 03:52 PM, Just van Rossum wrote:
> Ok. I've renamed the NibInfo.printOverview() method to 
> NibInfo.printTemplate().
> It will print a Python template with stubs for actions and comments 
> for outlets.
> NibLoader.py is converging back to classnib.py ;-)

Subsuming the features of classnib.py, more likely.

> The thing that I don't understand is why they are class attributes: 
> I'd expect
> (but then again, I don't grok them yet) they'd be specific to an 
> instance, and
> therefore be instance attributes. How does it work?

They are instance variables on the ObjC side.  If I declare an outlet 
named 'randomOutlet' and an action named 'randomAction:' in a class 
called ExampleObject and then generate the source, the following 
declaration results...

@interface ExampleObject : NSObject
{
     IBOutlet id randomOutlet;
}
- (IBAction)randomAction:(id)sender;
@end

... where IBOutlet and IBAction are declared as follows...

#define IBOutlet
#define IBAction void

IBOutlet and IBAction both exist for the sole purpose of providing for 
easy parsing of actions and outlets in IB itself.  There is nothing 
special about either declaration in terms of the ObjC language or at 
runtime.

When a NIB is loaded, it goes through a process of making the 
connections defined in the NIB (there are more than just outlets and 
actions, but we will ignore those for now).   For actions, this is 
simply a matter of setting the target and action for each object that 
has a target/action.   Literally, calling setTarget: and setAction: on 
each button, table, etc.. that has such set.   Target/action 
connections to FirstResponder simply setTarget: to nil (indicating that 
the action should be handled by the first responder in the chain that 
implements the action).

If the NIB has an object with a target/action connection where both the 
target and the action are set, but the runtime indicates that the 
target does not implement the action, the above error message is 
printed.

For Outlets, the connection process simply sets the instance variable 
directly, if possible.   However, before doing so, it checks to see if 
the object contains the method setOutletName: and, if so, calls that 
method instead, passing the object that it will be connected to as the 
first argument (i.e. if ExampleObject implemented -setRandomObject: it 
would be called instead of just making a direct connection).

Hope that helps (and looking at NibLoader, I'm not at all certain how 
the outlets are working... but they do seem to be working fine!)...

b.bum

[Pyobjc-dev] NIB Validation & action methods

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

For action methods, I would suggest not building the stub methods for 
each action.   Cocoa's nib loading mechanism already verifies that an 
action method exists as the NIB is loaded and, if not, will emit a 
message such as...

2002-11-16 16:29:47.283 example[1603] Could not connect the action 
randomAction: to target of class ExampleObject

... which serves nicely to remind the developer that that particular 
action method needs to be implemented.   Note that pushing the button 
that tried to connect that action doesn't do anything.

As far as outlets are concerned, validation becomes more difficult.   
Whether or not the outlet exists is determined by the configuration of 
the NIB file, not the developer and, as such, it is impossible-- given 
Just's most excellent code-- for the developer to 'use' an outlet that 
is not actually declared in the NIB (the developer can try, but they 
will get the classic KeyError style 'no such attribute' python 
exception).

b.bum

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

Ronald Oussoren wrote:

[ noop action stubs ]
> If you choose to do nothing you might as wel write the empty method 
> yourself (there is probably a reason for doing nothing). That way we 
> can do away with the flag and always warn if you don't implement all 
> actions.

Agreed. Will do.

> > (I don't grok outlets just yet: are the default IBOutlet objects all 
> > that are
> > ever needed, or are you supposed to provide them yourself?)
> 
> The default IBOutlets are all that is ever needed. You can set specific 
> types in Interface Builder, but those are all Objective-C classes and 
> those are all represented the same way in the Objective-C runtime.

Ok. I've renamed the NibInfo.printOverview() method to NibInfo.printTemplate().
It will print a Python template with stubs for actions and comments for outlets.
NibLoader.py is converging back to classnib.py ;-)

> I'd probably prefer to emit a warning when you do define IBOutlet 
> objects over doing it when you don't. Never warning at al is probably 
> best.
> 
> BTW. outlets are implemented using attributes/member variables in ObjC 
> code, IBOutlets perform the same task in PyObjC.

The thing that I don't understand is why they are class attributes: I'd expect
(but then again, I don't grok them yet) they'd be specific to an instance, and
therefore be instance attributes. How does it work?

Just

Re: [Pyobjc-dev] cvs commit rights

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

bb...@ma... wrote:

> What is the specific error?

just% cvs up
cvs server: failed to create lock directory for
`/cvsroot/pyobjc/pyobjc/Lib/AppKit'
(/cvsroot/pyobjc/pyobjc/Lib/AppKit/#cvs.lock): Permission denied
cvs server: failed to obtain dir lock in repository
`/cvsroot/pyobjc/pyobjc/Lib/AppKit'
cvs [server aborted]: read lock failed - giving up
just% 

> I may have screwed something up on the SF administrative front but it 
> could just as easily be an SF problem as I have seen a number of those 
> in the past.

Yeah, this sounds most likely... If it's not over by tomorrow I'll file a
support request.

Just

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

On Saturday, Nov 16, 2002, at 20:55 Europe/Amsterdam, Just van Rossum 
wrote:

>
>
>> And while we're at it: it would be a killer feature if NibLoader could
>> optionally use Python's introspection features to check that your
>> subclass actually implements all needed methods and such, so that if
>> you set NibLoader.DEBUG to true (or have that set automatically if the
>> environment variable PY_NIBLOADER_DEBUG is set) your classes are
>> checked for conforming to what the nib expects. Of course we can't go
>> any further than method names and number of arguments, but it would
>> still be a great tool.
>
> Right, this should actually be straightforward! What the 
> NibClassBuilder
> metaclass currently does is add stub methods for actions not defined 
> in the
> class itself, and add IBOutlets for outlets that haven't been defined
> "manually". It would be easy to print a warning to stderr at 
> class-build-time if
> an action isn't defined. I think this flag should be True by default, 
> though,
> since you're supposed to implement them all anyway. If you _choose_ to 
> just keep
> the noop stub, _then_ you should set the debug flag to false...

If you choose to do nothing you might as wel write the empty method 
yourself (there is probably a reason for doing nothing). That way we 
can do away with the flag and always warn if you don't implement all 
actions.

>
> (I don't grok outlets just yet: are the default IBOutlet objects all 
> that are
> ever needed, or are you supposed to provide them yourself?)

The default IBOutlets are all that is ever needed. You can set specific 
types in Interface Builder, but those are all Objective-C classes and 
those are all represented the same way in the Objective-C runtime.

I'd probably prefer to emit a warning when you do define IBOutlet 
objects over doing it when you don't. Never warning at al is probably 
best.

BTW. outlets are implemented using attributes/member variables in ObjC 
code, IBOutlets perform the same task in PyObjC.

Ronald

[Pyobjc-dev] cvs commit rights

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

On Saturday, November 16, 2002, at 02:55 PM, Just van Rossum wrote:
> PS: I still can't commit. Does anyone know whether it would be wise to 
> open an
> sf support request yet, or should I be a little more patient?

What is the specific error?

I may have screwed something up on the SF administrative front but it 
could just as easily be an SF problem as I have seen a number of those 
in the past.

b.bum

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

Jack Jansen wrote:

> On vrijdag, nov 15, 2002, at 11:39 Europe/Amsterdam, Ronald Oussoren 
> wrote:
> > We could of course use a variant of mknibwrapper to generate 
> > userfriendly documentation instead of a python file.
> 
> Not only documentation but also a skeleton implementation, similar to 
> the "generate .c/.h" from Interface Builder.

(Where is this functionality? Can't find any menu for it in IB...)

> And while we're at it: it would be a killer feature if NibLoader could 
> optionally use Python's introspection features to check that your 
> subclass actually implements all needed methods and such, so that if 
> you set NibLoader.DEBUG to true (or have that set automatically if the 
> environment variable PY_NIBLOADER_DEBUG is set) your classes are 
> checked for conforming to what the nib expects. Of course we can't go 
> any further than method names and number of arguments, but it would 
> still be a great tool.

Right, this should actually be straightforward! What the NibClassBuilder
metaclass currently does is add stub methods for actions not defined in the
class itself, and add IBOutlets for outlets that haven't been defined
"manually". It would be easy to print a warning to stderr at class-build-time if
an action isn't defined. I think this flag should be True by default, though,
since you're supposed to implement them all anyway. If you _choose_ to just keep
the noop stub, _then_ you should set the debug flag to false...

(I don't grok outlets just yet: are the default IBOutlet objects all that are
ever needed, or are you supposed to provide them yourself?)

Just

PS: I still can't commit. Does anyone know whether it would be wise to open an
sf support request yet, or should I be a little more patient?

Re: [Pyobjc-dev] New NibLoader.py

[Peter M. <zig...@po...>]

On Sunday, November 17, 2002, at 01:56 AM, Ronald Oussoren wrote:

> NibLoader is an enhanced version of the module objc.classnib. Neither 
> the original module nor the new version have a lot of documentation, 
> other than the code.
>
> The idea behind it all is simple: If you define a class in Interface 
> Builder (IB) it stores information about that class in a text file 
> inside the NIB. The module objc.classnib can be used to parse this 
> file and create stub python classes. This saves some typing and 
> removes a source of errors. I find this very convenient.

Ah, so it's sort of like "Create files" in IB?


> What Just did is rewrite this in such way that the text file is parsed 
> at runtime, removing another source of errors (forgetting to 
> regenerate the stub file after updating/adding class definitions in 
> Interface Builder) and of course showing of the flexibility of Python.

Cool... I'll have to have a closer look at it. I've been writing the 
classes manually.

Peter

Re: [Pyobjc-dev] New NibLoader.py

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

NibLoader is an enhanced version of the module objc.classnib. Neither 
the original module nor the new version have a lot of documentation, 
other than the code.

The idea behind it all is simple: If you define a class in Interface 
Builder (IB) it stores information about that class in a text file 
inside the NIB. The module objc.classnib can be used to parse this file 
and create stub python classes. This saves some typing and removes a 
source of errors. I find this very convenient.

What Just did is rewrite this in such way that the text file is parsed 
at runtime, removing another source of errors (forgetting to regenerate 
the stub file after updating/adding class definitions in Interface 
Builder) and of course showing of the flexibility of Python.

Ronald

Re: [Pyobjc-dev] New NibLoader.py

[Peter M. <zig...@po...>]

On Saturday, November 16, 2002, at 10:42 AM, bb...@ma... wrote:

> It works really well and has been integrated into the repository.  The 
> WebServicesTool project has been updated to take advantage of the new 
> nib management mechanism.

So what exactly is this NibLoader stuff for? When does one use it?

I tried to RTFM but I couldn't find anything.

Thanks,
Peter

Re: [Pyobjc-dev] New NibLoader.py

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

bb...@ma... wrote:

> It works really well and has been integrated into the repository.  The 
> WebServicesTool project has been updated to take advantage of the new 
> nib management mechanism.
> 
> I changed a few minor things [all open to debate, of course -- except 
> where it was a stupid bug fix I caused in the first place]:
> 
> - I changed the names from loadNib* to loadClassesForNib*.   This 
> better fits with Cocoa in that NibLoader isn't truly loading nibs, it 
> is loading the classes associated with the nibs -- one may invoke the 
> loadNib: method on NSBundle many, many times after the classes for the 
> Nib have been loaded (and this is exactly how multi-doc apps work).

Agreed, except I would leave out the "ForNib" part, it's part of NibLoader after
all. Mind if I change that once my commit rights are actually working?

Perhaps the NibInfo should keep track of what nibs it already has parsed. That
way you can call loadClasses[FromBundle] multiple times for one nib without
doing double work.

> - fixed a bug where it was passing .nib instead of 'nib' to NSBundle's 
> pathForResource_ofType_ (dumb).
> 
> In any case -- it works and works quite well.   The performance hit is 
> negligible.  With the features that allow one to dump the current 
> configuration of a NIB, it rounds out quite nicely.
> 
> I agree w/Ronald in that some advanced debugging/analysis tools would 
> be welcome!

I think the NibInfo.printOverview() method could be changed (and renamed) to
print a Python template, as Jack suggested.

> BTW:  Technically, the classes.nib file does not have to be present for 
> a NIB to work.  It is only used by PBX/IB to store the class 
> information.  However, I don't see it as a problem that we require the 
> file given that the developer can always fall back to the traditional 
> means of doing things.
> 
> However-- be forewarned that certain versions of nibtool -- the command 
> line nib manipulation tool -- have a habit of blowing away the 
> classes.nib.   Definitely something to look for when automatically 
> processing NIBs.

Is classes.nob the only way to get at the info we need, or is it simply the
simples one?

***

I'm again having second (third? ;-) thoughts again about whether I like the
__metaclass__ syntax better or the "magic baseclass". After all, *a* baseclass
is added. Naming is crucial, perhaps "NibAutoBaseClass" is a good name:

  from AppKit.NibLoader import NibAutoBaseClass
  from AppKit import NSTableSource
  
  class PyModel(NibAutoBaseClass, NSTableSource):
      ...

Opinions?

Just

Re: [Pyobjc-dev] New NibLoader.py

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

It works really well and has been integrated into the repository.  The 
WebServicesTool project has been updated to take advantage of the new 
nib management mechanism.

I changed a few minor things [all open to debate, of course -- except 
where it was a stupid bug fix I caused in the first place]:

- I changed the names from loadNib* to loadClassesForNib*.   This 
better fits with Cocoa in that NibLoader isn't truly loading nibs, it 
is loading the classes associated with the nibs -- one may invoke the 
loadNib: method on NSBundle many, many times after the classes for the 
Nib have been loaded (and this is exactly how multi-doc apps work).

- fixed a bug where it was passing .nib instead of 'nib' to NSBundle's 
pathForResource_ofType_ (dumb).

In any case -- it works and works quite well.   The performance hit is 
negligible.  With the features that allow one to dump the current 
configuration of a NIB, it rounds out quite nicely.

I agree w/Ronald in that some advanced debugging/analysis tools would 
be welcome!

BTW:  Technically, the classes.nib file does not have to be present for 
a NIB to work.  It is only used by PBX/IB to store the class 
information.  However, I don't see it as a problem that we require the 
file given that the developer can always fall back to the traditional 
means of doing things.

However-- be forewarned that certain versions of nibtool -- the command 
line nib manipulation tool -- have a habit of blowing away the 
classes.nib.   Definitely something to look for when automatically 
processing NIBs.

b.bum

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

[Jack J. <Jac...@or...>]

On vrijdag, nov 15, 2002, at 11:39 Europe/Amsterdam, Ronald Oussoren 
wrote:
> We could of course use a variant of mknibwrapper to generate 
> userfriendly documentation instead of a python file.

Not only documentation but also a skeleton implementation, similar to 
the "generate .c/.h" from Interface Builder.

And while we're at it: it would be a killer feature if NibLoader could 
optionally use Python's introspection features to check that your 
subclass actually implements all needed methods and such, so that if 
you set NibLoader.DEBUG to true (or have that set automatically if the 
environment variable PY_NIBLOADER_DEBUG is set) your classes are 
checked for conforming to what the nib expects. Of course we can't go 
any further than method names and number of arguments, but it would 
still be a great tool.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

[Jack J. <Jac...@or...>]

On vrijdag, nov 15, 2002, at 23:04 Europe/Amsterdam, bb...@ma... wrote:

> On Friday, November 15, 2002, at 02:30 PM, Ronald Oussoren wrote:
>>> class WSTApplicationDelegate (NibLoader):
>> This should be ... (NibLoader.NibLoader):
>
> Doh!  Defeated by the Obvious Yet Again!
>
> Instead of calling it 'NibLoader', how about NibSuper, NibAbstract, 
> NibBase, or something else other than the module name?  I have been 
> burned by this-- and have helped folks new to Python-- on this exact 
> same kind of a problem *so many times* now, that I really try to avoid 
> this kind of namespace overloading as much as possible.

It's standard Python idiom (if a module has a main class give them the 
same name), but now that the bases for a class can be pretty much 
everything that is callable, in stead of only modules as it used to be, 
it can lead to strange errors.

But I think NibLoader should be able to detect this situation (not sure 
though, I don't have the code handy, and I still haven't read Just's 
message which will hopefully finally make me understand metaclasses).
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

[Pyobjc-dev] New NibLoader.py

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

I've attached the current state of NibLoader.py. I would have checked it right
in, if I wasn't getting cvs errors (I think it may be because it takes a while
for new developers to get their permissions set up right, maybe it's a cron job
that runs only once a day?).

Lot's of things have changed, lots of cleanups. Instead if subclassing from a
magic object with a magic metaclass, you now have to specify a metaclass
explicitly:

  from AppKit import NSTableSource
  from AppKit.NibLoader import NibClassBuilder, loadNibFromBundle
  
  loadNibFromBundle("MainMenu")
  
  class PyModel(NSTableSource):
      __metaclass__ = NibClassBuilder

I think this is better as you see right away that something special is going on,
whereas subclassing from a magic object just looks like subclassing. I think
it's good that the magic stands out.

In private mail Jack and I talked about seeing nib files as something similar to
Python modules, so instead of the above one would do (say):

  class PyModel(NSTableSource):
      __metaclass__ = getClassBuilder("MainMenu")

However, this suggests that a nib file is a namespace. It's not. The same class
definition may occur in several nibs, but at runtime there can only exist one,
as Obj-C's class namespace is flat. So I think it's best/better to just keep a
global dict of classes, gathered from all nibs.

(The loading of nibs currently needs to be done with NibLoader.loadNib() or
NibLoader.loadNibFromBundle(), but I think it would be nice to have some
bootstrap code somewhere that just loads all nibs found the the app bundle.)

I've added a simple command line main program, which lets you print an overview
of classes in a set of nibs. I think this could satisfy Ronalds wish for a nib
"documentation" viewer. It's invoked like so:

  python NibLoader.py <path-to-nib> [more paths to nibs]

The program has one option, -t, that will run a simple test instead of printing
the overview.

(Style: I've mostly followed my own naming and coding style. If there's a
consensus about what style the pyobj project should follow, I'd gladly adopt
NibLoader to it. I have some opinions, but this gets religious real fast...)

Just

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

On Friday, November 15, 2002, at 02:30 PM, Ronald Oussoren wrote:
>> class WSTApplicationDelegate (NibLoader):
> This should be ... (NibLoader.NibLoader):

Doh!  Defeated by the Obvious Yet Again!

Instead of calling it 'NibLoader', how about NibSuper, NibAbstract, 
NibBase, or something else other than the module name?  I have been 
burned by this-- and have helped folks new to Python-- on this exact 
same kind of a problem *so many times* now, that I really try to avoid 
this kind of namespace overloading as much as possible.

Once changed, works flawlessly!

b.bum

Re: [Pyobjc-dev] NSTextView weirdness

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

Phew, I think I found the problem with NSTextView. I've just checked in 
a fix for this problem, it was caused by me not quite understanding how 
Python does method resolution: Instead of calling __getattr__ on the 
class the implementation directly looks inside the class __dict__. This 
bypasses a hook in the __getattr__ implementation of objc_class that is 
used to detect Objective-C classes whose method-table have been changed 
since the last attribute lookup.

BTW. Don't do 'NSTextView.alloc()', but always add an init* call. If 
you don't do this the program will crash. This is not a PyObjC problem, 
but a Cocoa problem ([[NSTextView alloc] release] causes a segfault).

I've opened bug reports with Apple about this, the [NSTextView alloc] 
problem using an NSInvocation (as described earlier) and the fact that 
NSOutlineView doesn't call retain on model objects even if it store 
references to them.

Ronald

On Wednesday, Nov 13, 2002, at 22:24 Europe/Amsterdam, bb...@ma... 
wrote:

> Is it the case that the class object is being released to the point of 
> death by the NSInvocation (and, subsequently, by the Python wrapper 
> for the ObjC object)?
>
> No... that isn't it... more like NSTextView.alloc() is returning 
> something similar to NSArray.alloc() that behaves in a slightly 
> different and more volatile fashion?
>
> Nuts.
>
> Yes, this was a part of debugging Steve's earlier problem and it still 
> doesn't address that problem.
>
>> If I evaluate NSTextView.setEditable_ before calling obj.setEditable_ 
>> all goes well. I'm still checking why this is necessary.
>
> I have not a clue and will be quite interested in the answer!
>
> b.bum
>
> On Wednesday, November 13, 2002, at 04:16 PM, Ronald Oussoren wrote:
>
>> Some more debugging shows:
>>
>> The test code is too complex, the code below also causes a crash:
>>
>> from AppKit import NSTextView
>> NSTextView.alloc()
>>
>> .....
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Are you worried about your web 
> server security? Click here for a FREE Thawte Apache SSL Guide and 
> answer your Apache SSL security needs: 
> http://www.gothawte.com/rd523.html
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

On Friday, Nov 15, 2002, at 17:29 Europe/Amsterdam, bb...@ma... wrote:

> [code committed]
>
> Unfortunately, I'm not having any luck modifying WebServicesTool to 
> use the loader.  If I do:
>
> from AppKit import NibLoader
>
> NibLoader.addNibFromBundle( "MainMenu.nib" )
>
> class WSTApplicationDelegate (NibLoader):
This should be ... (NibLoader.NibLoader):

Ronald

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

Ronald Oussoren wrote:

> While I like the idea, I feel there is a minor disadvantage to this 
> solution: With an explicit nibwrapper.py you can easily check which 
> methods you should implement and which outlets are available.

Yes, that crossed my mind.

> The advantage of your approach is that you do not have to worry about
> updating the nibwrapper.py file when you make relevant changes to a
> NIB file.

Exactly. I think that's a big win.

> The additional startup time is probably not very relevant
> (at least at the moment, loading the frameworks pretty expensive)

Right.

> We could of course use a variant of mknibwrapper to generate
> userfriendly documentation instead of a python file.

It would be trivial to add such a thing to NibLoader.py. I'll do so after the
next iteration of the module.

Just

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

While I like the idea, I feel there is a minor disadvantage to this 
solution: With an explicit nibwrapper.py you can easily check which 
methods you should implement and which outlets are available. The 
advantage of your approach is that you do not have to worry about 
updating the nibwrapper.py file when you make relevant changes to a NIB 
file. The additional startup time is probably not very relevant (at 
least at the moment, loading the frameworks pretty expensive)

We could of course use a variant of mknibwrapper to generate 
userfriendly documentation instead of a python file.

Ronald

On Friday, Nov 15, 2002, at 01:09 Europe/Amsterdam, Just van Rossum 
wrote:

> Today, instead of learning how to do useful things with Cocoa <wink>, 
> I wrote a
> replacement for mknibwrapper/objc.classnib.py, that does the same 
> thing at
> runtime, making nibwrapper.py files superfluous.
>
> This abviously has some startup time hit, but it seems quite quick. 
> Not that I
> think that having to generate nibwrapper.py files is all that bad, I 
> was just
> looking for an opportunity to learn a thing or two, eg. about 
> metaclasses...
>
> The attached module lets you do this:
>
>
>   [...more imports snipped...]
>   from NibLoader import NibLoader, addNib
>
>   # (the addNib() could be done elewhere, or could be done more
>   # concisely with a helper funciton in the NibLoader module)
>   addNib(os.path.join(sys.path[0], "English.lproj/MainMenu.nib"))
>
>   class PyModel(NibLoader, NSTableDataSource):
>       ...etc...
>
>
> addNib() parses a nib file and sucks the class info out of it.
> NibLoader is a magic class (or rather, has a magic superclass) that 
> will make
> sure the subclass has the right base class, and will populate it with 
> all the
> stuff that was normally generated in the nibwrapper file.
>
> So far I've only tested it with the TableModel demo: it works for me.
>
> The NibLoader module contains a tiny test program: you can invoke it 
> from the
> command line like so:
>
>   % python NibLoader.py <path-to-nib> [more paths to nibs]
>
> It will parse all nibs specified and will build dummy test classes for 
> all found
> nib classes and print some blurb to stdout. I've tested this on a few 
> nibs found
> in apps that came with the OS as well as with all the nibs in the 
> Examples
> folder, and apart from some classes that don't seem to have a 
> SUPERCLASS
> attribute, building the test classes seems to work.
>
> Obviously much of the code is ripped straight from objc/classnib.py.
>
> Useful?
>
> Just<NibLoader.py>

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

bb...@ma... wrote:

> Added to the CVS repository as Lib/AppKit/NibLoader.py.

Ah, I would have suggested to add it to objc, though. Also, I've already
completely rewritten it... And I'm having an offline discussion with Jack
(Cc-ing Ronald) about the design. Tonight I'll be able to post a new version and
outline the revised design, but now it's dinner time! If you want, can give me
commit rights, my sf name is "jvr".

Later,

Just

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

[code committed]

Unfortunately, I'm not having any luck modifying WebServicesTool to use  
the loader.  If I do:

from AppKit import NibLoader

NibLoader.addNibFromBundle( "MainMenu.nib" )

class WSTApplicationDelegate (NibLoader):
   def newConnectionAction_(self, sender):
      
WSTConnectionWindowController.connectionWindowController().showWindow_(s 
ender)

   def applicationDidFinishLaunching_(self, aNotification):
     self.newConnectionAction_(None)

... then, at runtime, I see ...

2002-11-15 11:26:58.092 Web Services Tool[24489] Process ID is: 24489 (
	gdb /usr/bin/python 24489
  to debug)
2002-11-15 11:27:08.624 Web Services Tool[24489] Unknown class  
`WSTApplicationDelegate' in nib file, using `NSObject' instead.
2002-11-15 11:27:08.639 Web Services Tool[24489] Could not connect the  
action newConnectionAction: to target of class NSObject

... It seems that the WSTApplicationDelegate class is not being defined  
in a fashion that is found by the ObjC side of the bridge?   Actually,  
If I do...

     print WSTApplicationDelegate
     print dir(WSTApplicationDelegate)

... after the class definition, the output changes to ...

<module '?' (built-in)>
[]
2002-11-15 11:29:30.565 Web Services Tool[24519] Unknown class  
`WSTApplicationDelegate' in nib file, using `NSObject' instead.
2002-11-15 11:29:30.567 Web Services Tool[24519] Could not connect the  
action newConnectionAction: to target of class NSObject

I'm confused now.

b.bum

Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

On Thursday, November 14, 2002, at 07:09 PM, Just van Rossum wrote:
> Today, instead of learning how to do useful things with Cocoa <wink>, 
> I wrote a
> replacement for mknibwrapper/objc.classnib.py, that does the same 
> thing at
> runtime, making nibwrapper.py files superfluous.

Excellent.

> This abviously has some startup time hit, but it seems quite quick. 
> Not that I
> think that having to generate nibwrapper.py files is all that bad, I 
> was just
> looking for an opportunity to learn a thing or two, eg. about 
> metaclasses...

The startup is minor in comparison to other startup issues and to the 
unarchival of the object graph contained in the NIB [I would think].   
Small price to pay in return for one less dependency within the 
development environment.

> It will parse all nibs specified and will build dummy test classes for 
> all found
> nib classes and print some blurb to stdout. I've tested this on a few 
> nibs found
> in apps that came with the OS as well as with all the nibs in the 
> Examples
> folder, and apart from some classes that don't seem to have a 
> SUPERCLASS
> attribute, building the test classes seems to work.

If a class doesn't have a SUPERCLASS, it should default to NSObject, I 
would think.  I'll look into this as I convert some of my projects over 
to using NibLoader.

> Obviously much of the code is ripped straight from objc/classnib.py.
>
> Useful?

Very.

Added to the CVS repository as Lib/AppKit/NibLoader.py.   I modified it 
to skip FirstResponder -- a class does not need to be created for 
FirstResponder (target/action directed at first responder indicates to 
the event handling system that the action should be sent to the first 
object in the responder chain that responds to the action).

I also added an addNibFromBundle() function that can be used like this:

     NibLoader.addNibFromBundle( "MainMenu.nib" )

It takes an optional second argument if you want to point it at a 
particular bundle or framework;  defaults to NSBundle.mainBundle().   
It uses NSBundle's pathForResource:ofType: method to find the NIB and, 
as such, will automatically load the NIB of the correct language in 
localized apps.

Ronald:  Does this supersede classnib?  I.e. should classnib be removed?

b.bum


b.bum
No Chunks...
	... No Foul!

[Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

Today, instead of learning how to do useful things with Cocoa <wink>, I wrote a
replacement for mknibwrapper/objc.classnib.py, that does the same thing at
runtime, making nibwrapper.py files superfluous.

This abviously has some startup time hit, but it seems quite quick. Not that I
think that having to generate nibwrapper.py files is all that bad, I was just
looking for an opportunity to learn a thing or two, eg. about metaclasses...

The attached module lets you do this:


  [...more imports snipped...]
  from NibLoader import NibLoader, addNib
  
  # (the addNib() could be done elewhere, or could be done more
  # concisely with a helper funciton in the NibLoader module)
  addNib(os.path.join(sys.path[0], "English.lproj/MainMenu.nib"))
  
  class PyModel(NibLoader, NSTableDataSource):
      ...etc...


addNib() parses a nib file and sucks the class info out of it.
NibLoader is a magic class (or rather, has a magic superclass) that will make
sure the subclass has the right base class, and will populate it with all the
stuff that was normally generated in the nibwrapper file.

So far I've only tested it with the TableModel demo: it works for me.

The NibLoader module contains a tiny test program: you can invoke it from the
command line like so:

  % python NibLoader.py <path-to-nib> [more paths to nibs]

It will parse all nibs specified and will build dummy test classes for all found
nib classes and print some blurb to stdout. I've tested this on a few nibs found
in apps that came with the OS as well as with all the nibs in the Examples
folder, and apart from some classes that don't seem to have a SUPERCLASS
attribute, building the test classes seems to work.

Obviously much of the code is ripped straight from objc/classnib.py.

Useful?

Just