pyobjc-dev — CVS commit notices go here

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

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

On Saturday, Nov 16, 2002, at 23:31 Europe/Amsterdam, bb...@ma... 
wrote:

> On Saturday, November 16, 2002, at 05:19 PM, Just van Rossum wrote:
>> bb...@ma... wrote:
>> [ great explanation snipped ]
>>
>>> 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).
>>
>> Ok, so the _runtime_ will add instance variables?
>
> [talking pure ObjC here] No -- in the case where -setRandomObject: is 
> implemented, there need not be an instance variable named randomObject 
> at all.   The connection mechanism assumes that since the developer 
> implemented the -set*: method, the developer is going to take care of 
> doing whatever they want/need with the object passed to the method.

Is this documented somewhere. I knew that the NSNibLoader class does 
something like this, but I didn't find information about it in the 
documentation at the time (early this summer, when Jack surprised me by 
using outlets when I was sure I hadn't added support for them yet)
>
> Ahhh... now I understand.   From the Python-Cocoa template, I see the 
> declaration of....
>
>   messageTextField = IBOutlet("messageTextField")
>
> ... but, in the implementation, I see...
>
>     self.messageTextField.setStringValue_( helloString )
>
> ... so, yes, it appears that IBOutlet() creates a declaration for an 
> ivar that is then shared among all classes.  Yet, each individual 
> instance gets its own instance variable slot for that particular ivar.

This is indeed true. IBOutlet does two things
1. It causes an instance variable to be added to the Objective-C side 
of the new class.
2. It defines a property for accessing this instance variable.

It is using the same mechanism as class property(object)
  |  property(fget=None, fset=None, fdel=None, doc=None) -> property 
attribute
  |
  |  fget is a function to be used for getting an attribute value, and 
likewise
  |  fset is a function for setting, and fdel a function for del'ing, an
  |  attribute.  Typical use is to define a managed attribute x:
  |  class C(object):
  |      def getx(self): return self.__x
  |      def setx(self, value): self.__x = value
  |      def delx(self): del self.__x
  |      x = property(getx, setx, delx, "I'm the 'x' property.")
  |

Ronald

P.S. Does anyone have a 'mailinglist-archive-to-documentation script? 
The mailinglist archives currently contain more usefull information 
than the documentation in the source archive.

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

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

On Saturday, Nov 16, 2002, at 23:34 Europe/Amsterdam, Just van Rossum 
wrote:

> bb...@ma... wrote:
>
>>> 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.
>>
>> Neither; when the NIB is loaded and the nib loading mechanism walks
>> through the connections to ensure that the appropriate target/action
>> methods can be connected.
>
> You mean when (eg.) a window is instantiated?
That is what I understood of it. This would only catch errors for 
actions that are actually used, not for actions that are defined but 
are not a target.

I prefer emitting warnings when the class is instantiated as this would 
give you a complete set of warnings during program startup. Actually 
only if you load all Nib classes during program startup but I've been 
doing that upto now.

>
>> This is the only time that such validation can occur.   Class
>> instantiation is too early as there may be additional methods added
>> to the class between the time the class is created and those methods
>> may contain the action implementations.
>
> Not sure if I get this. What NibLoader could do is, that as soon the 
> module
> containing the class is imported, it verifies the action methods 
> contained in
> the class body actually contain all the methods as specified in the 
> nib. How
> does this compare to what the Cocoa runtime does?

In Objective-C it is possible to define categories that in effect add 
new methods to an existing class interface. It is possible to load 
categories at runtime (NSString is one example in Cocoa, its interface 
is defined in Foundation and then enhanced in AppKit).

In Python you can also add new methods to a class. I'd not worry to 
much about this, if only because it will be less efficient to call 
those additional methods from Objective-C: The additional methods are 
called through an NSInvocation while the normal methods are called 
through more efficient method stubs.

Ronald

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

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

On Saturday, Nov 16, 2002, at 21:52 Europe/Amsterdam, Just van Rossum 
wrote:
>
>> 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?
>

IBOutlets properties, just like __builtin__.property. Those are defined 
in the class but have an effect in instances. Properties are part of 
the machinery introduced by new-style classes.

Ronald

Re: [Pyobjc-dev] Re: Making List<->Array bridging transparent

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

Bill,

     My apologies for not approving this message on the 10th.

	While PyObjC is designed to work with the out of the box installation 
from Apple, that is pretty much the lowest common denominator.   That 
is, a framework or unix build tends to have more capabilities than that 
Apple supplied build-- ssl support, readline, the full MacPython 
environment, etc.

     So, as such, do whatever is the easiest to manage in your 
environment.   PyObjC should "just work" with whatever you end up with.

     b.bum

On Sunday, November 10, 2002, at 01:01 PM, Bill Noon wrote:

> I am updating a number of machines to 10.2 and would like to start 
> working on some pyObjC
> projects.  I have been using the python 2.3 code and use a lot of unix 
> applications/libraries.
>
> The framework build has worked fine, but I am wondering whether 
> whether there is any preference
> between a framework install or a basic unix install.
>
> I want to distribute applications locally that can use packages from a 
> central place (whether
> /Library/Frameworks or /usr/local/lib/python2.3) and be linked to 
> python directly.
>
> Is there a preference?
>
> --Bill Noon
>
> On Sunday, November 10, 2002, at 12:43 PM, Ronald Oussoren wrote:
>
>> Long. Apple seems to have a long feature-freeze for the Darwin part 
>> of new OSX releases and Python 2.3 has not even reached an alpha 
>> release at the moment, I wouldn't be surprised if Python 2.3 isn't 
>> released before the summer of 2003.
>>
>> BTW. The alpha status of 2.3 doesn't mean that this version is 
>> unusable. I haven't really run into problems while using it the last 
>> couple of months.
>>
>> Ronald
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing 
> your web site with SSL, click here to get a FREE TRIAL of a Thawte 
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
b.bum
We gladly feast on those who would subdue us.

Re: [Pyobjc-dev] Separating functionality into modules

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

OK -- I take it back -- the help(Foundation) produces a remarkably 
useful hunk o' output:

NAME
     Foundation

FILE
     /usr/lib/python2.2/site-packages/Foundation/__init__.py

PACKAGE CONTENTS
     _Foundation
     __init__

CLASSES
     __builtin__.objc_object(__builtin__.object)
         NSFault
         NSInvocationBuilder
         NSObject
             %NSCFType
                 NSCFType
             %NSNull
                 NSNull
             %NSURL
                 NSURL
                     NSAbsoluteURL
             NSAEDescriptorTranslator
             NSAppleEventDescriptor
             NSAppleEventManager
....

Note that it is leaking classes that the developer would normally never 
encounter (NSCF*) and is exposing posing situations (the classes 
prepended with %).

Very cool...

b.bum

Re: [Pyobjc-dev] Separating functionality into modules

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

On Saturday, November 16, 2002, at 07:51 PM, Jack Jansen wrote:
>> None of this is to say that the extensions to the AppKit should not 
>> be separated out -- I have nothing against that, but I also am not 
>> strongly attracted to doing so.
>
> My main reason for suggesting this is support. If our AppKit is 
> Apple's AppKit except things we can't implement, and the 
> PyObjC-specific stuff (which either doesn't make sense for ObjC, or 
> which we've added because we think it's an omission on Apple's side) 
> is in a different place this should make it easier to look up stuff in 
> documentation. That should forestall questions to this group. And I'm 
> actually already slightly trembling at the thought of what might 
> happen once PyObjC gets decent exposure...

I can certainly understand that line of thinking and I have a feeling 
the exposure on PyObjC is going to grow fairly exponentially in the 
near future.

There are really two separate kinds of division we are discussing;  
division of PyObjC specific functionality and division of extensions to 
objc / AppKit / Foundation / Address Book.

The first is one that exists now, but is neither complete nor correct 
(not a criticism -- this isn't something that any of us have dumped a 
huge amount of thought into).  Mostly, there are bits specific to 
Foundation that are lumped down into objc.

The second division is the one that Jack describes above;  how to 
divide things such that our stuff vs. Apple's stuff is easy to 
differentiate.   (If I'm understanding the issue correctly).

Currently, help(Foundation) and help(AppKit) take a long, long time-- 
maybe forever-- and trigger some nasty warnings from the runtime.

In any case, it would seem that help(Foundation) and help(AppKit) 
should really only document the functionality that we provide or 
modify.  If something works exactly like it does in ObjC-- i.e. is a 
part of the Foundation or AppKit APIs-- then the developer should go 
straight to the source, I would think...?

I admit I haven't given nearly enough thought to this problem as I 
should.

b.bum

Re: [Pyobjc-dev] Separating functionality into modules

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

On zondag, nov 17, 2002, at 01:30 Europe/Amsterdam, bb...@ma... wrote:
> None of this is to say that the extensions to the AppKit should not be 
> separated out -- I have nothing against that, but I also am not 
> strongly attracted to doing so.

My main reason for suggesting this is support. If our AppKit is Apple's 
AppKit except things we can't implement, and the PyObjC-specific stuff 
(which either doesn't make sense for ObjC, or which we've added because 
we think it's an omission on Apple's side) is in a different place this 
should make it easier to look up stuff in documentation. That should 
forestall questions to this group. And I'm actually already slightly 
trembling at the thought of what might happen once PyObjC gets decent 
exposure...
--
- 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] Separating functionality into modules

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

On Saturday, November 16, 2002, at 07:18 PM, Jack Jansen wrote:
> What I do wonder, though, is whether this should be in AppKit. 
> Shouldn't we try to keep AppKit clean, so the Apple documentation 
> completely describes it, and put our own PyObjC-specific stuff 
> elsewhere? There isn't a good place right now, I think, but now might 
> be a good time to add one ("PyObjC" comes to mind as a name). Or does 
> the objc package fit this bill?

[The NibLoading mechanism] It makes more sense in AppKit than it does 
in objc.   The PyObjC bridge can be used outside of the context of the 
AppKit -- the AppKit is just a framework that adds a set of classes for 
use within ObjC.   Same goes for Foundation, technically -- the NSArray 
and NSDictionary glue should be moved into Foundation.

That objc mixes in bits from Foundation and AppKit is a bug, really -- 
though it also seems unavoidable in some cases.  The objc module should 
provide only what is necessary to provide the Python<->ObjC messaging 
bridge.   Anything specific to a particular framework should be 
elsewhere.

This will greatly contribute to supporting GnuStep.   As well, it makes 
it possible to use the bridge in contexts where one wants to use just 
the runtime, but none of the Foundation/AppKit classes -- 
Object/List/HashTable are still around and there are those [including 
me] who occasionally build new sets of classes that are not rooted at 
NSObject for research purposes.

None of this is to say that the extensions to the AppKit should not be 
separated out -- I have nothing against that, but I also am not 
strongly attracted to doing so.   In particular, part of the goal of 
the Foundation and AppKit modules is to provide seamless integration of 
the frameworks into Python -- this includes both mapping API [as does 
the various integration methods for NS* collections] and providing 
convenience functionality for working with the provided APIs.

b.bum

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

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

On zaterdag, nov 16, 2002, at 23:45 Europe/Amsterdam, Just van Rossum 
wrote:
> Do you have any thoughts about
>
>     from AppKit.NibClassBuilder import NibClassBuilder
>     class PyModel(NSTableSource):
>         __metaclass__ = NibClassBuilder
>         ...
>
> vs.
>
>     from AppKit.NibClassBuilder import AutoBaseClass
>     class PyModel(AutoBaseClass, NSTableSource):
>         ...
>
> ? Today I'm leaning towards the latter ;-)

So am I, I think the "Auto" in AutoBaseClass is a good enough 
indication that there's magic happening.

What I do wonder, though, is whether this should be in AppKit. 
Shouldn't we try to keep AppKit clean, so the Apple documentation 
completely describes it, and put our own PyObjC-specific stuff 
elsewhere? There isn't a good place right now, I think, but now might 
be a good time to add one ("PyObjC" comes to mind as a name). Or does 
the objc package fit this bill?
--
- 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] Newer NibLoader.py

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

Jack Jansen wrote:

> Is there a reason you like yours better than mine, or does it somehow 
> suit PyObjC better (I haven't looked at it for aeons... something like 
> 3 weeks:-)?

Yours checks for four filenames in Resources, whereas for a pyobjc project we
can just hardcode the main program from a template. Hm, you could do that, too
;-)

Yours is nicer in that it checks the existance of the main program.

> I would definitely prefer the MacPython and the PyObjC version of the 
> script to be the same, so if there's a good reason to use this one for 
> PyObjC I'll change the MacPython applet structure to use the name 
> realmain.py too (but convince me first:-).

Sorry, "realmain.py" is by no means a serious suggestion. I think it should read
%(mainprogram)s ;-)

> For people who don't track Python CVS: the difference is that in my 
> version I do
> for name in ["__rawmain__.py", "__rawmain__.pyc", "__main__.py", 
> "__main__.pyc"]:
> around the os.path.join(....., name). This gives me the current applet 
> naming scheme (__rawmain__, if it exists, will read AppleEvents for 
> ODOC's and stuff them into sys.argv and then call __main__, which can 
> then be a normal unix-style script but still get the files the user 
> dropped on the applet in sys.argv).

I was wondering about that: where do you do your argv emulation if not in _this_
little program? And if here, then you might as well use two templates. Or
three...

Just my 2c.

Re: [Pyobjc-dev] Newer NibLoader.py

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

On zondag, nov 17, 2002, at 00:23 Europe/Amsterdam, Just van Rossum 
wrote:
>   #!/usr/bin/env python
>
>   import os
>   from sys import argv, executable
>   realmain = os.path.join(os.path.dirname(os.path.dirname(argv[0])),
>                           "Resources", "realmain.py")
>   argv.insert(1, realmain)
>   os.execve(executable, argv, os.environ)
>
> This could be a template, where "realmain.py" is replaced with the 
> appropriate
> filename. (Jack has checked in a modified version into the Python CVS 
> tree that
> fits his needs better. Since it's such a trivial program, I don't 
> think it's bad
> to add our own template.)

Is there a reason you like yours better than mine, or does it somehow 
suit PyObjC better (I haven't looked at it for aeons... something like 
3 weeks:-)?

I would definitely prefer the MacPython and the PyObjC version of the 
script to be the same, so if there's a good reason to use this one for 
PyObjC I'll change the MacPython applet structure to use the name 
realmain.py too (but convince me first:-).

For people who don't track Python CVS: the difference is that in my 
version I do
for name in ["__rawmain__.py", "__rawmain__.pyc", "__main__.py", 
"__main__.pyc"]:
around the os.path.join(....., name). This gives me the current applet 
naming scheme (__rawmain__, if it exists, will read AppleEvents for 
ODOC's and stuff them into sys.argv and then call __main__, which can 
then be a normal unix-style script but still get the files the user 
dropped on the applet in sys.argv).

--
- 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] Another naive question

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

bb...@ma... wrote:

> [ ... ]   Unfortunately, from AppKit import NSApplication causes the
> AppKit module to effectively visit every class in the runtime as a
> part of initialization -- and this is quite expensive.

Ah, so that's the bottleneck. I'd be intersted in figuring out whether this can
be done lazily, but I'll need to familiarize myself with the source first...

Just

Re: [Pyobjc-dev] Another naive question

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

On Saturday, November 16, 2002, at 06:39 PM, Just van Rossum wrote:
> What is the real difference between:
>
>>>> from AppKit import NSApplication
>
> and
>
>>>> from objc import *
>>>> NSApplication = lookup_class("NSApplication")
>
> ? (I noticed they're one and the same object.)

The second gives access to the class directly without doing any of the 
other convenience style stuff found in the AppKit module (informal 
protocol declarations, etc.).   Unfortunately, from AppKit import 
NSApplication causes the AppKit module to effectively visit every class 
in the runtime as a part of initialization -- and this is quite 
expensive.

b.bum

[Pyobjc-dev] Another naive question

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

What is the real difference between:

  >>> from AppKit import NSApplication
  
and
  
  >>> from objc import *
  >>> NSApplication = lookup_class("NSApplication")

? (I noticed they're one and the same object.)

I guess the real question is what does the AppKit module _do_ that makes
importing take so long? Erm, I'm not complaining, just being curious...

Just

[Pyobjc-dev] Re: Newer NibLoader.py

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

Committed with one slight modification;  removed the - in front of the 
outlets....

Started to think about changing it such that it would output a class 
declaration in a form that could be used in place of the automatic 
class definition mechanism provided by the NibLoader mechanism.

b.bum

On Saturday, November 16, 2002, at 06:23 PM, Just van Rossum wrote:

> I've submitted an sf support request regarding my cvs problems. In the 
> meantime,
> here is my working version, still named NibLoader.py. The command line 
> program
> prints a complete Python template, using AutoBaseClass. (I'll think a 
> bit more
> about your naming suggestions.) Currently the __metaclass__ = 
> NibClassLoader
> idiom still works, but I'm tempted to rip it out... I'd be interested 
> in
> comments from Ronald and Jack, though.

[Pyobjc-dev] Newer NibLoader.py

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

bb...@ma... wrote:

> Assuming the changes are going to be relatively small from here out, 
> I'm going to change the Cocoa-Python project accordingly. 

I've submitted an sf support request regarding my cvs problems. In the meantime,
here is my working version, still named NibLoader.py. The command line program
prints a complete Python template, using AutoBaseClass. (I'll think a bit more
about your naming suggestions.) Currently the __metaclass__ = NibClassLoader
idiom still works, but I'm tempted to rip it out... I'd be interested in
comments from Ronald and Jack, though.

> I may also look into using a pure python main, as well.

That one I recently posted ;-):

  #!/usr/bin/env python

  import os
  from sys import argv, executable
  realmain = os.path.join(os.path.dirname(os.path.dirname(argv[0])),
                          "Resources", "realmain.py")
  argv.insert(1, realmain)
  os.execve(executable, argv, os.environ)

This could be a template, where "realmain.py" is replaced with the appropriate
filename. (Jack has checked in a modified version into the Python CVS tree that
fits his needs better. Since it's such a trivial program, I don't think it's bad
to add our own template.)

Just

Re: [Pyobjc-dev] New NibLoader.py

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

On Saturday, November 16, 2002, at 06:00 PM, Just van Rossum wrote:
> bb...@ma... wrote:
>
>> Actually, yes, I do mind. :-)
>
> Ok, I see your points, and I agree. Yet, maybe it can be simpler (this 
> _is_
> Python after all ;-). How about this:
>
>   Load classes from nib named "nibName" from main bundle:
>
>       loadClasses(nibName)
>
>   Load classes from nib named "nibName" from bundle "aBundle":
>
>       loadClasses(nibName, bundle=aBundle)
>
>   Load classes from nib by file path:
>
>       loadClasses(path=pathToNib)

Works for me... elegant, as well.   Clean in that way that is so 
natural to Python -- similar to the metaclass solution used by the nib 
loader to determine the base classes.   I wasn't familiar with that, at 
all.

>
> [ ... ]
>> So, all things considered, nothing really need be changed.  I'm not
>> sure what happens in Cocoa if you load two NIB files that have the 
>> same
>> class defined but the intention was that they were to be different
>> classes.  [ ... ]
>
> (The code I ripped from AppKit/classnib.py asserts they have the same 
> baseclass;
> the outlets and actions lists are merged.)

Relatively undefined behavior in both cases, then -- defined, but 
probably not what the developer intended in either case.

b.bum

Re: [Pyobjc-dev] New NibLoader.py

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

On Saturday, November 16, 2002, at 05:24 AM, Just van Rossum wrote:
>> 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.nib the only way to get at the info we need, or is it 
> simply the
> simples one?

Only way that I know of that will work without some seriously nasty 
hackery involving the InterfaceBuilder APIs...

b.bum

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

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

On Saturday, November 16, 2002, at 05:45 PM, Just van Rossum wrote:
> Ok, things are getting somewhat clearer, thanks! (But now I'm 
> wondering who's
> setting these ivars: is it Cocoa or the Py/Obj-C bridge?)

Ronald can answer with specifics....

In general, the declaration of an iVar in ObjC, whether done 
programmatically or in the @interface, creates a slot in the instances 
of that class into which the iVar's value can be stored.   Sounds 
complex?  It isn't -- just think of an instance of a class as a big C 
structure.   Subclassing is done by simply unioning the parent classes 
with the child.

The ObjC runtime provides API for getting and setting the values within 
an instance structure directly.  With the lack of a -set*: style 
method, this is exactly what the IB connection mechanism does.

And these are the exact methods that the ObjC bridge uses.  See 
instance-var.m.

...
         if (strcmp(var->ivar_type, "@") == 0) {
                 object_setInstanceVariable(objc, self->name, *(id*)buf);
         } else {
                 object_setInstanceVariable(objc, self->name, 
*(void**)buf);
         }
...

As long as you explicitly declare a class attribute to be an ivar it'll 
work like an ivar.  valueForKey: and takeValue:forKey: are a part of 
the very cool NSKeyValueCoding protocol found in the Foundation.   Like 
any instance of a python class can be treated as dictionaries and the 
values can be accessed directly [oversimplification, I know], 
NSKeyValueCoding allows the same to be done to ObjC classes.   An 
example (first declaration shows what happens when you don't declare 
the class attribute as a true iVar... and, I know, the semantics are 
very different between bar-as-a-python-class-attribute and 
bar-as-an-objc-instance-variable.

 >>> from Foundation import *
 >>> class Foo(NSObject):
...     bar = 1
...     def foo(self): return self.bar
...
 >>> x = Foo.alloc().init()
 >>> x.foo
<bound method Foo.foo of <Foo objective-c instance 0xc98990>>
 >>> x.bar
1
 >>> x.bar = 2
 >>> x.bar
2
 >>> x.foo()
2
 >>> x.valueForKey_("foo")
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
objc.error: NSUnknownKeyException - [<Foo 0xc98990> valueForKey:]: 
lookup of unknown key: 'foo'.
This class does not have an instance varia
 >>> from objc import *
 >>> class Bar(NSObject):
...     bar = ivar('bar')
...
 >>> x = Bar.alloc().init()
 >>> x.bar
 >>> x.bar = 1
 >>> x.bar
1
 >>> x.valueForKey_('bar')
1

Re: [Pyobjc-dev] New NibLoader.py

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

bb...@ma... wrote:

> Actually, yes, I do mind. :-)

Ok, I see your points, and I agree. Yet, maybe it can be simpler (this _is_
Python after all ;-). How about this:

  Load classes from nib named "nibName" from main bundle:

      loadClasses(nibName)
  
  Load classes from nib named "nibName" from bundle "aBundle":

      loadClasses(nibName, bundle=aBundle)
  
  Load classes from nib by file path:

      loadClasses(path=pathToNib)

[ ... ]
> So, all things considered, nothing really need be changed.  I'm not 
> sure what happens in Cocoa if you load two NIB files that have the same 
> class defined but the intention was that they were to be different 
> classes.  [ ... ]

(The code I ripped from AppKit/classnib.py asserts they have the same baseclass;
the outlets and actions lists are merged.)

Just

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

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

On Saturday, November 16, 2002, at 05:45 PM, Just van Rossum wrote:
> Do you have any thoughts about
>
>     from AppKit.NibClassBuilder import NibClassBuilder
>     class PyModel(NSTableSource):
>         __metaclass__ = NibClassBuilder
>         ...
>
> vs.
>
>     from AppKit.NibClassBuilder import AutoBaseClass
>     class PyModel(AutoBaseClass, NSTableSource):
>         ...
>
> ? Today I'm leaning towards the latter ;-)

I like the former because it strikes to my weakness for Meta Object 
Protocols. However, the latter prevents the developer from confusing 
the heck out of me by moving the __metaclass__ = ... to the very end of 
the class declaration.  So, I'm leaning to the latter as well.

Instead of AutoBaseClass, how about 'DeriveSuperFromNib'  or 
'SuperDerivedFromNib' or 'BaseDerivedFromNib'?

But, AutoBaseClass works too...

Assuming the changes are going to be relatively small from here out, 
I'm going to change the Cocoa-Python project accordingly.  I may also 
look into using a pure python main, as well.

b.bum

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

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

On Saturday, November 16, 2002, at 05:34 PM, Just van Rossum wrote:
> bb...@ma... wrote:
>>> 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.
>>
>> Neither; when the NIB is loaded and the nib loading mechanism walks
>> through the connections to ensure that the appropriate target/action
>> methods can be connected.
>
> You mean when (eg.) a window is instantiated?

NIB loading basically happens in two passes:

- all objects contained in the object graph within the NIB are 
unarchived (this is an oversimplification -- see the 'deferred' 
functionality on NSWindow -- irrelevant for this discussion, though 
very interesting it is)

- all of the NIB connections are made

The second step is when the validation occurs.  So, it happens after 
instantiation but before the first action is sent.  Through 
-awakeFromNib, the developer is given the opportunity to further edit 
the object graph before the first action is sent.

>> This is the only time that such validation can occur.   Class
>> instantiation is too early as there may be additional methods added
>> to the class between the time the class is created and those methods
>> may contain the action implementations.
>
> Not sure if I get this. What NibLoader could do is, that as soon the 
> module
> containing the class is imported, it verifies the action methods 
> contained in
> the class body actually contain all the methods as specified in the 
> nib. How
> does this compare to what the Cocoa runtime does?

A step back for a second:  The NibLoader.py that exists now doesn't 
really have anything to do directly with NIB loading and has everything 
to do with defining new Objective-C classes.   NibLoader provides the 
developer with an incredible convenience;  the developer no longer has 
to worry about keeping their source files in sync with the reality 
perpetuated by the NIB file.

NIB loading happens much later.

Furthermore, the typical Cocoa application will have a need to user the 
classes that may potentially be defined via NibLoader long before the 
NIB file is actually loaded.   Consider the case of a Preferences 
controller.  The controller may provide API for retrieving and setting 
preferences values that are used application wide.  It may also provide 
various actions/outlets via which it controls the display of 
preferences in a preferences panel.   The preferences controller may be 
instantiated long before the preferences UI is ever displayed (and the 
UI may never be displayed).

In terms of validation, the validation of the target/action connections 
made in a NIB file cannot be made until the NIB file itself is actually 
loaded.   Consider this very bogus example:

 >>> class MyFoo(NSObject): pass
...
 >>> def barAction_(self, sender): print "responding to bar -- %s" % 
sender
...
 >>> MyFoo.barAction_ = barAction_

Now, imagine that the definition of the MyFoo class was the result of 
using NibLoader, which found the MyFoo class in the NIB file.  Sometime 
between the initial definition of the class MyFoo and the loading of 
the NIB file, the developer has added the barAction_() method to MyFoo 
-- in traditional ObjC, this is likely because they loaded an NSBundle 
that contains a category on the MyFoo class that added the additional 
method(s).

This is actually a pretty common situation given the responder chain.  
By simply tossing some action methods into a category on NSApplication 
or NSWindow, then setting the target of a menu item or button to nil 
while setting the action to be the newly added methods, that action can 
be triggered from anywhere in the UI.   Similar tricks can be done to 
add new functionality to every button, every field, every text view, 
every table view, or any other subset of objects.

With python, the ability to derive new methods programmatically and add 
them at will makes it all the more powerful.

In any case, the end result is that the target/action connectivity 
cannot be validated when the class is initially defined as a 
combination of what is found in the NIB and what the developer has 
directly implemented -- there may be new method implementations added 
before the NIB is loaded that will fill in the missing pieces, 
effectively.

b.bum

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

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

bb...@ma... wrote:

> Ahhh... now I understand.   From the Python-Cocoa template, I see the=20
> declaration of....
>=20
>    messageTextField =3D IBOutlet("messageTextField")
>=20
> .... but, in the implementation, I see...
>=20
>      self.messageTextField.setStringValue_( helloString )
>=20
> .... so, yes, it appears that IBOutlet() creates a declaration for an=20
> ivar that is then shared among all classes.  Yet, each individual=20
> instance gets its own instance variable slot for that particular ivar.

Ok, things are getting somewhat clearer, thanks! (But now I'm wondering w=
ho's
setting these ivars: is it Cocoa or the Py/Obj-C bridge?)

> Slightly confusing from the Python perspective, definitely.   My ObjC=20
> background is such that I didn't think twice about it until just now.=20
> :-)
>=20
> > PS: should we rename NibLoader.py to something more appropriate, too?
>=20
> Yes, it probably should be renamed as it is not analogous with=20
> NSNibLoading at all.   I'm not sure what, though.
>=20
> NibClassLoader?

Or NibClassBuilder?

Do you have any thoughts about

    from AppKit.NibClassBuilder import NibClassBuilder
    class PyModel(NSTableSource):
        __metaclass__ =3D NibClassBuilder
        ...

vs.

    from AppKit.NibClassBuilder import AutoBaseClass
    class PyModel(AutoBaseClass, NSTableSource):
        ...

? Today I'm leaning towards the latter ;-)

Just
=B4

Re: [Pyobjc-dev] New NibLoader.py

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

On Saturday, November 16, 2002, at 05:24 AM, Just van Rossum wrote:
> 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?

Actually, yes, I do mind. :-)

Not for the basic loadClassesForNib() method -- simply loadClasses( 
pathToNib ) makes sense and reduces redundancy.

However, for loadClassesForNibInBundle(), it would be reduced to 
loadClassesInBundle() which doesn't really make sense in that it 
implies that all the classes in a bundle are to be loaded.

None of this means I'm married to the existing naming scheme.  Not at 
all -- I would just like a naming scheme that gives a bit more 
indication as to what is going on than just dropping the 'ForNib' from 
the two methods.

Actually, loadClassesForNibInBundle() should really be...

     loadClassesForNibNamed( aName, targetBundle=aBundle )

... as this follows the NSNibLoading API a bit more closely while also 
adding the ability to optionally specify the bundle from which the NIBs 
should be loaded.

> 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.

It likely should.  The common idiom I have been using to define classes 
that are source from NIBs is this:

NibLoader.loadClassesForNibFromBundle( "MainMenu" )
class AppDelegate (NSDraggingDestination):
   __metaclass__ = NibLoader.NibClassBuilder

   .....

That is, immediately before the class declaration, I make sure the NIB 
file that defines the class has had its classes extracted and created.  
  I would have expected that if I were to do the following, it would 
fail on the second load of MainMenu, but it doesn't.

NibLoader.loadClassesForNibFromBundle( "MainMenu" )
NibLoader.loadClassesForNibFromBundle( "MainMenu" )
class AppDelegate (NSDraggingDestination):
   __metaclass__ = NibLoader.NibClassBuilder

   .....

So, all things considered, nothing really need be changed.  I'm not 
sure what happens in Cocoa if you load two NIB files that have the same 
class defined but the intention was that they were to be different 
classes.  (The lack of true namespaces has long been one serious 
disadvantage to ObjC and is the reason why classes are all prefixed 
w/NS -- back in the NS 3.3 and prior days, they weren't and it caused 
no end of confusion.)

b.bum

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

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

bb...@ma... wrote:

> > 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.
> 
> Neither; when the NIB is loaded and the nib loading mechanism walks
> through the connections to ensure that the appropriate target/action
> methods can be connected.

You mean when (eg.) a window is instantiated?

> This is the only time that such validation can occur.   Class
> instantiation is too early as there may be additional methods added
> to the class between the time the class is created and those methods
> may contain the action implementations.

Not sure if I get this. What NibLoader could do is, that as soon the module
containing the class is imported, it verifies the action methods contained in
the class body actually contain all the methods as specified in the nib. How
does this compare to what the Cocoa runtime does?

Just