pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] Does PyObjC have a wiki?

[Jiva D. <ji...@de...>]

If not, I'd like to set one up.  Specifically, since I see a big issue 
right now being documentation related, I think having a Wiki, where we 
can all contribute tips/etc would be cool.  Any objections?

I have the server space and wiki software (moinmoin) already, so it's 
just a matter of saying "Go"

Re: [Pyobjc-dev] Categories (was: Subclassing NSTextField)

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

On Wednesday, Dec 18, 2002, at 16:44 Europe/Amsterdam, Peter Montagner 
wrote:

> I don't know if this is what you want but it may help:
>
> http://www.cocoadev.com/index.pl?MethodSwizzling

Swapping methods? Hah, we can do better than that :-) Nice to see that 
it is not only us bridge-builders that poke around in the Objective-C 
runtime.

> Peter
>
> On Thursday, December 19, 2002, at 01:41 AM, bb...@ma... wrote:
>
>> On Wednesday, Dec 18, 2002, at 01:32 US/Eastern, Ronald Oussoren 
>> wrote:
>>> On Tuesday, Dec 17, 2002, at 21:08 Europe/Amsterdam, bb...@ma... 
>>> wrote:
>>>> On Tuesday, Dec 17, 2002, at 14:25 US/Eastern, Steven D. Arnold 
>>>> wrote:
>>>>> On a related note, is there any mechanism to implement categories 
>>>>> in pyobjc?
>>>>> I thought this question had been asked before, but I couldn't find 
>>>>> it in my
>>>>> archive.
>>>>
>>>> Good question:   Ronald?
>>>
>>> Not really. You can of course implemenent methods from a category 
>>> for your own subclasses (e.g. like the text* categories Bill 
>>> mentioned in the previous message), but you cannot add new methods 
>>> to existing Objective-C classes. You can add new methods to 
>>> subclasses defined in Python.
>>
>> Some random notes...  (more Internet as a todo list -- also a lot of 
>> this can be answered more specifically by looking at the darwin 
>> source -- i don't have net connectivity right now, though).
>>
>> How are categories found in bundles currently loaded into the 
>> runtime?   Specifically, I see a declaration for a category structure 
>> in objc.h/objc-load.h/objc-class.h, but the only add methods API is 
>> this...
>>
>> OBJC_EXPORT void class_addMethods(Class, struct objc_method_list *);
>> OBJC_EXPORT void class_removeMethods(Class, struct objc_method_list 
>> *);
>>
>> ... which is also interesting in that it appears that removing 
>> methods is naturally supported by ObjC?  Didn't know that.

The class_addMethods function is probably what is used to load 
categories. Categories are not really objects in the runtime.

>>
>>> Some other useful things you cannot do at the moment (using the 
>>> Internet as my Todo list :-) are:
>>> - Adding new methods to subclassses implemented in Python if those 
>>> methods override/extend existing methods. You can do this, but your 
>>> method won't be called if someone tries to access this method from 
>>> Objective-C.
>>
>> Is this a matter of invoking class_addMethods() with the appropriate 
>> objc_method_list?

Yes it is and that should be easy enough. With the current codebase 
this is only doable if you're adding to a python-defined class, when I 
get around to playing with libffi again we should be able to also add 
methods to pure Objective-C classes.

>>
>>> - Removing methods from subclasses implemented in Python, if those 
>>> methods override/extend existing methods. Again you can actually do 
>>> this, but this doesn't have the right semantics.
>>
>> Not sure what you mean.   It certainly isn't something that is 
>> commonly done in ObjC-- I don't think I have ever seen methods 
>> removed from classes in the 15 years I have been doing ObjC-- but the 
>> API appears to support this.  This assumes that class_removeMethods() 
>> is more than a no-op.

When you're experimenting it might be usefull to just delete an 
existing method from a Python class (maybe because you just added it 
and found out this wasn't really what you wanted to do). If you remove 
a method you want that calls to that selector now go to the superclass.

Say you have:
	class FooObject (NSObject):
		def hash(self):
			return 0xff

	obj = FooObject.alloc().init()

After experimenting with this you decide that your implementation isn't 
very usefull and decide you can to without it:
	del FooObject.hash

You'd expected that obj.hash() ends up calling NSObject.hash instead of 
causing an error because the Python class no longer implements hash.

>>
>>> - Redefine an existing class. This is a feature: Because Objective-C 
>>> has a flat namespace and python doesn't you might otherwise 
>>> accidently replace and existing class. It is also not really 
>>> possible to implement this without memory leaks.
>>
>> Right.  In this case, enforcing the ObjC semantics of 
>> once-a-class-always-the-same-class is the way to go.
During incremental development it might be usefull to replace existing 
classes, but that should not be the default behaviour. Just completely 
redefining an existing class by adding and removing methods might be 
just as usefull.

In Python 2.3 it will also be possible to dynamicly change the class 
hierarchy for new-type classes. Supporting this in PyObjC might be neat.

>>
>>> All of these would be usefull for incremental development and may be 
>>> added in some future version (that includes support for categories).
>>
>> It would be useful for more than incremental development.
>>
>> Categories-- as much as they can be horrendously abused-- are a 
>> fairly fundamental part of the ObjC development experience.
>>
>> If we can redefine existing methods on the fly-- swizzle methods-- 
>> then we can build some incredibly powerful introspection and 
>> debugging tools.  Namely, we could potentially replace existing ObjC 
>> methods in a fashion where the existing functionality remains 
>> unchanged but some random method is invoked before and/or after the 
>> normal implementation.  For debugging, this would be HUGE!
Doing that is not too hard. If you want to do this with 'pure' 
Objective-C classes things get a harder, but using libffi (or a simular 
library) this should still be doable. But you shouldn't trust my 
judgement on timing: I once said that getting PyObjC in a more usefull 
shape (w.r.t. using NIB files) should take about 2 weeks :-)

Ronald

Re: [Pyobjc-dev] PyObjC 0.8 Release Candidate

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

On Wednesday, Dec 18, 2002, at 17:27 Europe/Amsterdam, Jiva DeVoe wrote:

>
> On Tuesday, December 17, 2002, at 09:57  PM, Bill Bumgarner wrote:
>
>> No, not currently.   Two issues:
>>
>> (1) you'll need a third party install of Python 2.2 or greater.  Fink 
>> or the MacPython community can supply such a beast.
>>
>> (2) you will need to regenerate the automatically generated types and 
>> enums based on the 10.1 headers.  This is easier than it sounds, but 
>> requires steps that have not been well documented.
>>
>
> Is it documented at all?
Not at all at the moment. Luckily regenerating isn't too hard. Basicly 
it is:
$ cd Modules/Cocoa && scripts/cocoa_generator.py

This will generate a number of files (the '.inc' files in 
Modules/Cocoa). Hopefully you won't have to edit the results.

> I'll second the request for information on how to run it on 10.1.x... 
> please point us in the right direction on this.

I'd like to support 10.1.x, but I don't have time to work on that right 
now. Patches to add that support out of the box are of course welcome 
;-) ;-)

Ronald

Re: [Pyobjc-dev] PyObjC 0.8 Release Candidate

[Jiva D. <ji...@de...>]

On Tuesday, December 17, 2002, at 09:57  PM, Bill Bumgarner wrote:

> No, not currently.   Two issues:
>
> (1) you'll need a third party install of Python 2.2 or greater.  Fink 
> or the MacPython community can supply such a beast.
>
> (2) you will need to regenerate the automatically generated types and 
> enums based on the 10.1 headers.  This is easier than it sounds, but 
> requires steps that have not been well documented.
>

Is it documented at all?  I'll second the request for information on 
how to run it on 10.1.x... please point us in the right direction on 
this.

> b.bum
>
> On Tuesday, Dec 17, 2002, at 20:38 US/Eastern, Bill Bedford wrote:
>
>> At 7:03 pm -0500 17/12/02, Bill Bumgarner wrote:
>>
>>> I have *finally* made a cut of PyObjC that is 0.8 release candidate
>>> worthy.
>>>
>>
>> Does it work with OS 10.1.x ?
>>
>>
>> -- 
>>
>> Bill Bedford
>>
>> He said no more is no less than it is
>> if in the future we live in the past
>>
> b.bum
> We gladly feast on those who would subdue us.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility Learn to use your power 
> at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] Categories (was: Subclassing NSTextField)

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

Yeah, I thought it looked a bit strange. I thought I'd send it to you 
anyway just in case.

Peter

On Thursday, December 19, 2002, at 02:51 AM, bb...@ma... wrote:

> On Wednesday, Dec 18, 2002, at 10:44 US/Eastern, Peter Montagner wrote:
>> I don't know if this is what you want but it may help:
>>
>> http://www.cocoadev.com/index.pl?MethodSwizzling
>
> Personally, I'm intimately familiar with method swizzling-- having 
> used it many times to wreak havoc upon an application. :-)
>
> His example isn't very good -- he could have used Posing to achieve 
> the same thing.
>
> The code is fairly clean, but has some issues. There is no need to 
> swizzle the types-- the types should not change without serious risk 
> of crashing.
>
> There is no need to actually declare a method.  His alt method could 
> easily have been declared as a C function:
>
> void alt_method(T *self, SEL _cmd) {
>     ...
> }
>
> This allows one to define the method without knowing the class 
> declaration in the first place-- which is where swizzling is most 
> useful (i.e. editing classes for which you do not have a declaration 
> that can be used to compile against).
>
> b.bum
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Order your Holiday Geek Presents 
> Now!
> Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated 
> Soap,
> MP3 Players,  XBox Games,  Flying Saucers,  WebCams,  Smart Putty.
> T H I N K G E E K . C O M       http://www.thinkgeek.com/sf/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] Categories (was: Subclassing NSTextField)

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

On Wednesday, Dec 18, 2002, at 10:44 US/Eastern, Peter Montagner wrote:
> I don't know if this is what you want but it may help:
>
> http://www.cocoadev.com/index.pl?MethodSwizzling

Personally, I'm intimately familiar with method swizzling-- having used 
it many times to wreak havoc upon an application. :-)

His example isn't very good -- he could have used Posing to achieve the 
same thing.

The code is fairly clean, but has some issues. There is no need to 
swizzle the types-- the types should not change without serious risk of 
crashing.

There is no need to actually declare a method.  His alt method could 
easily have been declared as a C function:

void alt_method(T *self, SEL _cmd) {
     ...
}

This allows one to define the method without knowing the class 
declaration in the first place-- which is where swizzling is most 
useful (i.e. editing classes for which you do not have a declaration 
that can be used to compile against).

b.bum

Re: [Pyobjc-dev] Categories (was: Subclassing NSTextField)

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

I don't know if this is what you want but it may help:

http://www.cocoadev.com/index.pl?MethodSwizzling

Peter

On Thursday, December 19, 2002, at 01:41 AM, bb...@ma... wrote:

> On Wednesday, Dec 18, 2002, at 01:32 US/Eastern, Ronald Oussoren wrote:
>> On Tuesday, Dec 17, 2002, at 21:08 Europe/Amsterdam, bb...@ma... 
>> wrote:
>>> On Tuesday, Dec 17, 2002, at 14:25 US/Eastern, Steven D. Arnold 
>>> wrote:
>>>> On a related note, is there any mechanism to implement categories 
>>>> in pyobjc?
>>>> I thought this question had been asked before, but I couldn't find 
>>>> it in my
>>>> archive.
>>>
>>> Good question:   Ronald?
>>
>> Not really. You can of course implemenent methods from a category for 
>> your own subclasses (e.g. like the text* categories Bill mentioned in 
>> the previous message), but you cannot add new methods to existing 
>> Objective-C classes. You can add new methods to subclasses defined in 
>> Python.
>
> Some random notes...  (more Internet as a todo list -- also a lot of 
> this can be answered more specifically by looking at the darwin source 
> -- i don't have net connectivity right now, though).
>
> How are categories found in bundles currently loaded into the runtime? 
>   Specifically, I see a declaration for a category structure in 
> objc.h/objc-load.h/objc-class.h, but the only add methods API is 
> this...
>
> OBJC_EXPORT void class_addMethods(Class, struct objc_method_list *);
> OBJC_EXPORT void class_removeMethods(Class, struct objc_method_list *);
>
> ... which is also interesting in that it appears that removing methods 
> is naturally supported by ObjC?  Didn't know that.
>
>> Some other useful things you cannot do at the moment (using the 
>> Internet as my Todo list :-) are:
>> - Adding new methods to subclassses implemented in Python if those 
>> methods override/extend existing methods. You can do this, but your 
>> method won't be called if someone tries to access this method from 
>> Objective-C.
>
> Is this a matter of invoking class_addMethods() with the appropriate 
> objc_method_list?
>
>> - Removing methods from subclasses implemented in Python, if those 
>> methods override/extend existing methods. Again you can actually do 
>> this, but this doesn't have the right semantics.
>
> Not sure what you mean.   It certainly isn't something that is 
> commonly done in ObjC-- I don't think I have ever seen methods removed 
> from classes in the 15 years I have been doing ObjC-- but the API 
> appears to support this.  This assumes that class_removeMethods() is 
> more than a no-op.
>
>> - Redefine an existing class. This is a feature: Because Objective-C 
>> has a flat namespace and python doesn't you might otherwise 
>> accidently replace and existing class. It is also not really possible 
>> to implement this without memory leaks.
>
> Right.  In this case, enforcing the ObjC semantics of 
> once-a-class-always-the-same-class is the way to go.
>
>> All of these would be usefull for incremental development and may be 
>> added in some future version (that includes support for categories).
>
> It would be useful for more than incremental development.
>
> Categories-- as much as they can be horrendously abused-- are a fairly 
> fundamental part of the ObjC development experience.
>
> If we can redefine existing methods on the fly-- swizzle methods-- 
> then we can build some incredibly powerful introspection and debugging 
> tools.  Namely, we could potentially replace existing ObjC methods in 
> a fashion where the existing functionality remains unchanged but some 
> random method is invoked before and/or after the normal 
> implementation.  For debugging, this would be HUGE!
>
> b.bum
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility Learn to use your power 
> at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] Categories (was: Subclassing NSTextField)

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

On Wednesday, Dec 18, 2002, at 01:32 US/Eastern, Ronald Oussoren wrote:
> On Tuesday, Dec 17, 2002, at 21:08 Europe/Amsterdam, bb...@ma... 
> wrote:
>> On Tuesday, Dec 17, 2002, at 14:25 US/Eastern, Steven D. Arnold wrote:
>>> On a related note, is there any mechanism to implement categories in 
>>> pyobjc?
>>> I thought this question had been asked before, but I couldn't find 
>>> it in my
>>> archive.
>>
>> Good question:   Ronald?
>
> Not really. You can of course implemenent methods from a category for 
> your own subclasses (e.g. like the text* categories Bill mentioned in 
> the previous message), but you cannot add new methods to existing 
> Objective-C classes. You can add new methods to subclasses defined in 
> Python.

Some random notes...  (more Internet as a todo list -- also a lot of 
this can be answered more specifically by looking at the darwin source 
-- i don't have net connectivity right now, though).

How are categories found in bundles currently loaded into the runtime?  
  Specifically, I see a declaration for a category structure in 
objc.h/objc-load.h/objc-class.h, but the only add methods API is this...

OBJC_EXPORT void class_addMethods(Class, struct objc_method_list *);
OBJC_EXPORT void class_removeMethods(Class, struct objc_method_list *);

... which is also interesting in that it appears that removing methods 
is naturally supported by ObjC?  Didn't know that.

> Some other useful things you cannot do at the moment (using the 
> Internet as my Todo list :-) are:
> - Adding new methods to subclassses implemented in Python if those 
> methods override/extend existing methods. You can do this, but your 
> method won't be called if someone tries to access this method from 
> Objective-C.

Is this a matter of invoking class_addMethods() with the appropriate 
objc_method_list?

> - Removing methods from subclasses implemented in Python, if those 
> methods override/extend existing methods. Again you can actually do 
> this, but this doesn't have the right semantics.

Not sure what you mean.   It certainly isn't something that is commonly 
done in ObjC-- I don't think I have ever seen methods removed from 
classes in the 15 years I have been doing ObjC-- but the API appears to 
support this.  This assumes that class_removeMethods() is more than a 
no-op.

> - Redefine an existing class. This is a feature: Because Objective-C 
> has a flat namespace and python doesn't you might otherwise accidently 
> replace and existing class. It is also not really possible to 
> implement this without memory leaks.

Right.  In this case, enforcing the ObjC semantics of 
once-a-class-always-the-same-class is the way to go.

> All of these would be usefull for incremental development and may be 
> added in some future version (that includes support for categories).

It would be useful for more than incremental development.

Categories-- as much as they can be horrendously abused-- are a fairly 
fundamental part of the ObjC development experience.

If we can redefine existing methods on the fly-- swizzle methods-- then 
we can build some incredibly powerful introspection and debugging 
tools.  Namely, we could potentially replace existing ObjC methods in a 
fashion where the existing functionality remains unchanged but some 
random method is invoked before and/or after the normal implementation. 
  For debugging, this would be HUGE!

b.bum

Re: [Pyobjc-dev] Categories (was: Subclassing NSTextField)

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

On Tuesday, Dec 17, 2002, at 21:08 Europe/Amsterdam, bb...@ma... wrote:

> On Tuesday, Dec 17, 2002, at 14:25 US/Eastern, Steven D. Arnold wrote:
>
>> On a related note, is there any mechanism to implement categories in 
>> pyobjc?
>> I thought this question had been asked before, but I couldn't find it 
>> in my
>> archive.
>
> Good question:   Ronald?

Not really. You can of course implemenent methods from a category for 
your own subclasses (e.g. like the text* categories Bill mentioned in 
the previous message), but you cannot add new methods to existing 
Objective-C classes. You can add new methods to subclasses defined in 
Python.

Some other useful things you cannot do at the moment (using the 
Internet as my Todo list :-) are:
- Adding new methods to subclassses implemented in Python if those 
methods override/extend existing methods. You can do this, but your 
method won't be called if someone tries to access this method from 
Objective-C.
- Removing methods from subclasses implemented in Python, if those 
methods override/extend existing methods. Again you can actually do 
this, but this doesn't have the right semantics.
- Redefine an existing class. This is a feature: Because Objective-C 
has a flat namespace and python doesn't you might otherwise accidently 
replace and existing class. It is also not really possible to implement 
this without memory leaks.

All of these would be usefull for incremental development and may be 
added in some future version (that includes support for categories).

Ronald

Re: [Pyobjc-dev] PyObjC 0.8 Release Candidate

[Bill B. <bb...@co...>]

No, not currently.   Two issues:

(1) you'll need a third party install of Python 2.2 or greater.  Fink 
or the MacPython community can supply such a beast.

(2) you will need to regenerate the automatically generated types and 
enums based on the 10.1 headers.  This is easier than it sounds, but 
requires steps that have not been well documented.

b.bum

On Tuesday, Dec 17, 2002, at 20:38 US/Eastern, Bill Bedford wrote:

> At 7:03 pm -0500 17/12/02, Bill Bumgarner wrote:
>
>> I have *finally* made a cut of PyObjC that is 0.8 release candidate
>> worthy.
>>
>
> Does it work with OS 10.1.x ?
>
>
> -- 
>
> Bill Bedford
>
> He said no more is no less than it is
> if in the future we live in the past
>
b.bum
We gladly feast on those who would subdue us.

Re: [Pyobjc-dev] PyObjC 0.8 Release Candidate

[Bill B. <bi...@mo...>]

At 7:03 pm -0500 17/12/02, Bill Bumgarner wrote:

>I have *finally* made a cut of PyObjC that is 0.8 release candidate
>worthy.
>

Does it work with OS 10.1.x ?


-- 

Bill Bedford

He said no more is no less than it is
if in the future we live in the past

[Pyobjc-dev] PyObjC 0.8 Release Candidate

[Bill B. <bb...@co...>]

I have *finally* made a cut of PyObjC that is 0.8 release candidate 
worthy.

The disk image can be found at:

     http://pyobjc.sourceforge.net/software/PyObjC-0.8.dmg.gz

Many, many, many changes.   See the ChangeLog -- included on the disk 
image -- for details.

Please, please test this as much as you can and give me feedback.  I 
want to try and target a general public release on Thursday or Friday.  
  (I probably should have marked this as rc1 or something, but I would 
really like to believe that no changes will be made between now and 
release -- spelling errors and other uglies can remain... I'm only 
concerned about things that make it go boom.)

Thanks,

b.bum

Re: [Pyobjc-dev] Subclassing NSTextField

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

On Tuesday, Dec 17, 2002, at 14:25 US/Eastern, Steven D. Arnold wrote:
> Hi,
>
> I may be having several misconceptions here, but I've looked at several
> sources without success, so I thought I'd ask.  I want to examine the 
> keys
> that are typed into an NSTextField, so I subclassed NSTextField in IB. 
>  In
> IB, I drew an NSTextField and set its custom class to my new class.  
> Then in
> Main.py I defined the class as follows:
>
> class SearchTextField( AppKit.NSTextField ):
>
>     #def init( self ):
>     #    print "initializing SearchTextField"
>     #    return self
>
>     def keyDown_( self, the_event ):
>         the_keys = the_event.characters()
>         print "Received keys: ", the_keys
>
> It was my understanding that this should be sufficient; the new
> SearchTextField should use the class I defined.  But I don't see my
> diagnostic message when I type.

Editing of Text in the AppKit doesn't work quite like that.   When a 
field becomes first responder & takes key, the window creates a field 
editor that is used to do the actual editing.  The field editor more or 
less "floats above" the field.

If you are looking for validation type behavior, you would want to 
create a custom Formatter.

Given that your class is named 'SearchTextField', I'm guess you want to 
implement something like auto complettion and/or automatching as the 
user types?

If that is the case, then have a look at the NSComboButton (or whatever 
it is called) as it support auto completion.  If that doesn't address 
your needs, then you'll need to look at the text editing and control 
editing delegate protocols:

@interface NSObject(NSControlSubclassDelegate)

// These delegate and notification methods are sent from NSControl 
subclasses that allow text editing such as NSTextField and NSMatrix.  
The classes that need to send these have delegates.  NSControl does not.

- (BOOL)control:(NSControl *)control textShouldBeginEditing:(NSText 
*)fieldEditor;
- (BOOL)control:(NSControl *)control textShouldEndEditing:(NSText 
*)fieldEditor;
- (BOOL)control:(NSControl *)control didFailToFormatString:(NSString 
*)string errorDescription:(NSString *)error;
- (void)control:(NSControl *)control 
didFailToValidatePartialString:(NSString *)string 
errorDescription:(NSString *)error;
- (BOOL)control:(NSControl *)control isValidObject:(id)obj;

- (BOOL)control:(NSControl *)control textView:(NSTextView *)textView 
doCommandBySelector:(SEL)commandSelector;
@end

...and....

@interface NSObject(NSTextDelegate)
- (BOOL)textShouldBeginEditing:(NSText *)textObject; /* YES means do it 
*/
- (BOOL)textShouldEndEditing:(NSText *)textObject; /* YES means do it */
- (void)textDidBeginEditing:(NSNotification *)notification;
- (void)textDidEndEditing:(NSNotification *)notification;
- (void)textDidChange:(NSNotification *)notification; /* Any keyDown or 
paste which changes the contents causes this */

The second only being applicable to NSText objects, I believe.

In generaly, you wouldn't want to override -keyDown: on a NSTextField 
directly unless you really, really want to customize text entry 
behavior.

> I also tried uncommenting the init function above, also with no effect 
> (i.e.
> No diagnostic message when the app is starting up).  I have it 
> commented out
> because I assumed the standard init function the class inherits from
> NSTextField was good enough.

-init is not the designated initializer for NSView subclasses;  
generally, -initWithFrame: is.

> On a related note, is there any mechanism to implement categories in 
> pyobjc?
> I thought this question had been asked before, but I couldn't find it 
> in my
> archive.

Good question:   Ronald?

b.bum

[Pyobjc-dev] Subclassing NSTextField

[Steven D. A. <st...@ne...>]

Hi,

I may be having several misconceptions here, but I've looked at several
sources without success, so I thought I'd ask.  I want to examine the keys
that are typed into an NSTextField, so I subclassed NSTextField in IB.  In
IB, I drew an NSTextField and set its custom class to my new class.  Then in
Main.py I defined the class as follows:

class SearchTextField( AppKit.NSTextField ):

    #def init( self ):
    #    print "initializing SearchTextField"
    #    return self

    def keyDown_( self, the_event ):
        the_keys = the_event.characters()
        print "Received keys: ", the_keys

It was my understanding that this should be sufficient; the new
SearchTextField should use the class I defined.  But I don't see my
diagnostic message when I type.

I also tried uncommenting the init function above, also with no effect (i.e.
No diagnostic message when the app is starting up).  I have it commented out
because I assumed the standard init function the class inherits from
NSTextField was good enough.

On a related note, is there any mechanism to implement categories in pyobjc?
I thought this question had been asked before, but I couldn't find it in my
archive.

steve
-- 

Re: [Pyobjc-dev] Re: deallocating python/objc hybrids

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

On Monday, Dec 16, 2002, at 15:48 US/Eastern, Ronald Oussoren wrote:
> On Sunday, Dec 15, 2002, at 21:33 Europe/Amsterdam, bb...@ma... wrote:
>> On Sunday, Dec 15, 2002, at 14:56 US/Eastern, Ronald Oussoren wrote:
>>> After I checked this in it came to my mind that changing the class 
>>> of remaining half of the object might be a cleaner way to do. 
>>> Currently the program will fail because of unimplemented methods if 
>>> [super release] calls methods that were overridden in Python. As the 
>>> user cannot do anything about this just changing the type of 'self' 
>>> might be more usefull ('self->isa = self->isa->superclass;' instead 
>>> of the if-statement in the code above).
... stuff snorked for brevity's sake ...
>> Assigning self->isa to self->isa->superclass is problematic, as well.
> Why would 'self->isa = self->isa->superclass' be problematic? This 
> would be a hackish way to achieve the previous item. There actually is 
> a precedent for this: This is basically what happens during the 
> destruction of C++ objects (if I recall this correctly, I haven't done 
> C++ programming for some time).

If someone had overridden one of the cleanup methods to do some cleanup 
of their own or avoid super's cleanup entirely, this behavior would 
cause problems.   A rarity, certainly, but still very confusing and 
hard to debug.

>> This sounds like you are fighting a battle that may not need to be 
>> fought.   If I understand correctly, this will only occur if the 
>> Python part of the object is destroyed before the ObjC side and, 
>> hence, the walk up the -release tree can cause problems?   
>> Specifically, the problem occurs when the metainformation used to 
>> glue the ObjC and Python objects together is released before the ObjC 
>> side is done with it?
>
> It specifically happens while deallocating the Python/Objective-C 
> hybrid. As it is impossible to deallocate both at the same time, we'll 
> have to do it in some order. The current implementation first 
> deallocates the Python half and then the Objective-C half (most 
> specific part first). That this happens during a call to release 
> rather than dealloc is a result of the implementation. Details escape 
> me at the moment, but is has something to do with getting the 
> reference counts right. Hmm, I see some documentation coming...
>
> How would you do this in Objective-C? Do you call [super dealloc] at 
> the start of the end of -dealloc, or maybe in the middle? I suppose 
> you have to call it at the end. But what if [super dealloc] calls a 
> method that has been overridden and uses some already cleaned-up 
> resources?

Generic [i.e. pure ObjC] Dealloc's should always be written as...

- (void) dealloc
{
     ... release my instance variables, but not super's or sub's ...
     [super dealloc];
}

With PyObjC, nothing changes:

class Foo (ObjCBar):
     def dealloc(self):
	    self.baz = None
	    self.bob = None
	    super(ObjCBar, self).dealloc()

That is just the developer's perspective.  There is still the meta 
information that needs to be deallocated -- the glue between the two 
world's and the instance information that resides on the Python side.   
It should be considered separately from the -dealloc implementation.

When the chained -dealloc is executed, nothing should be destroyed on 
the Python side of the bridge (or in the bridge itself) until after the 
ObjC side has destroyed the instance.  That is:

- (void) dealloc
{
     ... dealloc ivars ...
     [super dealloc];  ... chain to super ...
     ... dealloc bridge meta information here ...
}

The last step should not involve deallocating any state that was a part 
of the instance as created by the developer (i.e. self.baz = None).   
It should only involve deallocating the structures associated with the 
instance-- the metadata that was used to encapsulate the instance in a 
fashion that allowed for it to survive on both sides of the bridge.

Stepping way outside my realm of expertise, maybe a weak reference 
between self and the collection of metadata is in order?

> I suppose you have to call it at the end. But what if [super dealloc] 
> calls a method that has been overridden and uses some already 
> cleaned-up resources?

If the bridged -dealloc is structured as above, then it doesn't matter 
if [super dealloc] calls a method that has been overridden.  The ivars 
may have already been cleaned-- that is a developer problem, not a 
problem of the bridge-- but the meta data should still exist and, 
hence, the object should still be messageable.

Once it hits the 'dealloc bridge meta information', the fact that self 
no longer references a messageable object on the ObjC side should not 
make a difference?

b.bum

[Pyobjc-dev] Re: deallocating python/objc hybrids

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

On Sunday, Dec 15, 2002, at 21:33 Europe/Amsterdam, bb...@ma... wrote:

>
> On Sunday, Dec 15, 2002, at 14:56 US/Eastern, Ronald Oussoren wrote:
>> After I checked this in it came to my mind that changing the class of 
>> remaining half of the object might be a cleaner way to do. Currently 
>> the program will fail because of unimplemented methods if [super 
>> release] calls methods that were overridden in Python. As the user 
>> cannot do anything about this just changing the type of 'self' might 
>> be more usefull ('self->isa = self->isa->superclass;' instead of the 
>> if-statement in the code above).
>
> Would it be possible to mark the object such that attempts to invoke 
> methods on the object that were formerly implemented on the python 
> side behave as messages-to-nil?
That would be possible, but would probably have bad side-effects. These 
method-calls are probably done to do some cleanup (deallocating 
resources etc.). Calling the super-class implementation is probably the 
best way to achieve this.

>
> Alternatively, could the dispatcher check to see if the python side 
> exists and, if not, call super's implementation?  Likely, no -- that 
> is probably a bad idea.

>
> Assigning self->isa to self->isa->superclass is problematic, as well.
Why would 'self->isa = self->isa->superclass' be problematic? This 
would be a hackish way to achieve the previous item. There actually is 
a precedent for this: This is basically what happens during the 
destruction of C++ objects (if I recall this correctly, I haven't done 
C++ programming for some time).

>
> --
>
> This sounds like you are fighting a battle that may not need to be 
> fought.   If I understand correctly, this will only occur if the 
> Python part of the object is destroyed before the ObjC side and, 
> hence, the walk up the -release tree can cause problems?   
> Specifically, the problem occurs when the metainformation used to glue 
> the ObjC and Python objects together is released before the ObjC side 
> is done with it?

It specifically happens while deallocating the Python/Objective-C 
hybrid. As it is impossible to deallocate both at the same time, we'll 
have to do it in some order. The current implementation first 
deallocates the Python half and then the Objective-C half (most 
specific part first). That this happens during a call to release rather 
than dealloc is a result of the implementation. Details escape me at 
the moment, but is has something to do with getting the reference 
counts right. Hmm, I see some documentation coming...

How would you do this in Objective-C? Do you call [super dealloc] at 
the start of the end of -dealloc, or maybe in the middle? I suppose you 
have to call it at the end. But what if [super dealloc] calls a method 
that has been overridden and uses some already cleaned-up resources?

Ronald

Re: [Pyobjc-dev] Looking for Cocoa Book

[Jiva D. <ji...@de...>]

I'll second the Hillegas book... just go to Amazon and do a search by 
author Hillegas.

On Sunday, December 15, 2002, at 07:07  PM, Isaac Levy wrote:

> Hey all,
>
> After a nice trip over tho the local Barnes and Noble, I was kinda 
> confused by the Cocoa books available.
>
> Bill mentioned these ones to me a while back, but I couldn't find them:
>
> On Monday, December 2, 2002, at 10:46 AM, Bill Bumgarner wrote:
>> I would highly recommend that you grab a copy of Aaron Hillegas' 
>> Cocoa book [and Garfinkel's/Mahoney's book] and learn Cocoa/ObjC via 
>> those books -- they are both excellent.
>
> Does anyone on the list know exactly where I can find these books, or 
> what their exact titles are?
>
> Or- does anyone recommend the Oreilley Cocoa book?
>
> Thanks!
> .ike
>
>
>
>   Isaac Levy
> + Office of Structured Systems
>   http://structuredsystems.net
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility Learn to use your power 
> at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] So...

[Jiva D. <ji...@de...>]

So it's easy to deploy an app on 10.2 using the built in python.  The 
user doesn't even have to know my app is written in python.  What if I 
wanted to also deploy on 10.1 with similar ease?  Can I include my own 
python interpreter or something somehow?  How can I do this?

[Pyobjc-dev] Looking for Cocoa Book

[Isaac L. <is...@st...>]

Hey all,

After a nice trip over tho the local Barnes and Noble, I was kinda 
confused by the Cocoa books available.

Bill mentioned these ones to me a while back, but I couldn't find them:

On Monday, December 2, 2002, at 10:46 AM, Bill Bumgarner wrote:
> I would highly recommend that you grab a copy of Aaron Hillegas' Cocoa 
> book [and Garfinkel's/Mahoney's book] and learn Cocoa/ObjC via those 
> books -- they are both excellent.

Does anyone on the list know exactly where I can find these books, or 
what their exact titles are?

Or- does anyone recommend the Oreilley Cocoa book?

Thanks!
.ike



   Isaac Levy
+ Office of Structured Systems
   http://structuredsystems.net

Re: [Pyobjc-dev] Two difficulties with document-based app

[David E. <epp...@ic...>]

On 12/15/02 8:50 PM +0100 Ronald Oussoren <ous...@ci...> wrote:
> I've just checked in a patch that removes the crash. I'm pretty sure this
> fixes the problem, but it might not be the right way to fix this.

Thanks, I'm not seeing the crashes any more after installing this patch.
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Modules/objc class-builder.m,1.7,1.8 pyobjc.h,1.8,1.9

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

On Sunday, Dec 15, 2002, at 14:56 US/Eastern, Ronald Oussoren wrote:
> After I checked this in it came to my mind that changing the class of 
> remaining half of the object might be a cleaner way to do. Currently 
> the program will fail because of unimplemented methods if [super 
> release] calls methods that were overridden in Python. As the user 
> cannot do anything about this just changing the type of 'self' might 
> be more usefull ('self->isa = self->isa->superclass;' instead of the 
> if-statement in the code above).

Would it be possible to mark the object such that attempts to invoke 
methods on the object that were formerly implemented on the python side 
behave as messages-to-nil?

Alternatively, could the dispatcher check to see if the python side 
exists and, if not, call super's implementation?  Likely, no -- that is 
probably a bad idea.

Assigning self->isa to self->isa->superclass is problematic, as well.

--

This sounds like you are fighting a battle that may not need to be 
fought.   If I understand correctly, this will only occur if the Python 
part of the object is destroyed before the ObjC side and, hence, the 
walk up the -release tree can cause problems?   Specifically, the 
problem occurs when the metainformation used to glue the ObjC and 
Python objects together is released before the ObjC side is done with 
it?

If that is the case, structure the -release something like:

-(void) release
{
     ... release ivar stuff here ...
     [super release];
     ... release meta information here ...
}

Pure conjecture-- you know about 2 orders of magnitude more about this 
piece of the bridge than I.

b.bum

[Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Modules/objc class-builder.m,1.7,1.8 pyobjc.h,1.8,1.9

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

On Sunday, Dec 15, 2002, at 20:36 Europe/Amsterdam, Ronald Oussoren 
wrote:
[most of the patch removed]
> ! 	if (obj->ob_refcnt <= 0) {
> ! 		
> ! 		/* Remove reference to the Python object. We don't need it
> ! 		 * any more (because the ObjCObject code will remove it
> ! 		 * when this function returns) and [super release] may
> ! 		 * call back to us some time later on ([NSWindow release] in
> ! 		 * a seperator thread).
> ! 		 */
> ! 		if (ObjC_SetPythonImplementation(self, 0) == -1) {
> ! 		       ObjCErr_ToObjC();
> ! 		       return;
> ! 		}
> !

After I checked this in it came to my mind that changing the class of 
remaining half of the object might be a cleaner way to do. Currently 
the program will fail because of unimplemented methods if [super 
release] calls methods that were overridden in Python. As the user 
cannot do anything about this just changing the type of 'self' might be 
more usefull ('self->isa = self->isa->superclass;' instead of the 
if-statement in the code above).

Ronald

Re: [Pyobjc-dev] Two difficulties with document-based app

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

I've just checked in a patch that removes the crash. I'm pretty sure 
this fixes the problem, but it might not be the right way to fix this.

Ronald

On Friday, Dec 13, 2002, at 17:57 Europe/Amsterdam, David Eppstein 
wrote:

> On 12/13/02 11:22 AM +0100 Ronald Oussoren <ous...@ci...> wrote:
>> That's too bad. I've yet really tried to reproduce your problem, but 
>> from
>> your description your trying to do something like the Todo example. 
>> That
>> example does not crash. Could you try to build a simpler test case?
>
> Ok, a test case is attached to this email.  Usage:
> - Build and run from within projectbuilder
> - Make a new window with Cmd-N.  You should see a log message about a 
> new document.
> - Close the window with Cmd-W.  After a few seconds, on my computer, 
> the program crashes with a bus error.
>
> I tried some further simplifications beyond what I'm sending, and the 
> program stopped crashing, but I don't know whether that's because 
> everything here is necessary to trigger it or whether the 
> simplifications moved memory allocations around enough to mask the > bug.
>
> --
> David Eppstein       UC Irvine Dept. of Information & Computer Science
> epp...@ic... http://www.ics.uci.edu/~eppstein/
> <crashy.tar.gz>

Re: [Pyobjc-dev] How to get NSDoc subclass's window outlet?

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

Oh!  You are absolutely correct.  I apologize -- I didn't read the docs 
correctly.

It doesn't work because it shouldn't. :-)

> self.windowControllers()[0].window() works though.

Is the correct way to go about it, ugly though it is.

However, if you need direct access to the window, it is likely that 
there is an alternative design pattern that may be a bit more clean.

b.bum

On Sunday, Dec 15, 2002, at 12:41 US/Eastern, David Eppstein wrote:

> On 12/15/02 9:32 AM -0500 bb...@ma... wrote:
>> Generally, you never should or need to access an instance variable of
>> AppKit classes directly, even when subclassing.  An accessor method is
>> almost always provided.
>>
>> In this case, NSDocument implements the -window method for exactly 
>> this
>> purpose.
>>
>> Try self.window().
>>
>> If that doesn't work, then there is a bug.
>
> It doesn't work.  exception: No attribute window
> window() is also not documented in the AppKit API reference although 
> setWindow:() is there (with a note saying don't call it).
>

Re: [Pyobjc-dev] How to get NSDoc subclass's window outlet?

[David E. <epp...@ic...>]

On 12/15/02 9:32 AM -0500 bb...@ma... wrote:
> Generally, you never should or need to access an instance variable of
> AppKit classes directly, even when subclassing.  An accessor method is
> almost always provided.
>
> In this case, NSDocument implements the -window method for exactly this
> purpose.
>
> Try self.window().
>
> If that doesn't work, then there is a bug.

It doesn't work.  exception: No attribute window
window() is also not documented in the AppKit API reference although 
setWindow:() is there (with a note saying don't call it).

self.windowControllers()[0].window() works though.
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/