pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zachery Bir (zbir)
Assigned to: Nobody/Anonymous (nobody)
Summary: NSWindow.contentRectForFrameRect_styleMask_ not a class meth

Initial Comment:
Trying the following snippet of code:

    def showPrefPane(self, pane, sender):
        windowFrame = 
NSWindow.contentRectForFrameRect_styleMask_(
            NSWindow,
            self.window().frame(), 
self.window().styleMask())
        newWindowHeight = NSHeight(pane.frame())
        if self.window().toolbar().isVisible():
            newWindowHeight += NSHeight(
                
self.window().toolbar()._toolbarView().frame())
        newWindowFrame = 
NSWindow.frameRectForContentRect_styleMask_(
            NSWindow,
            NSMakeRect(NSMinX(windowFrame),
                       NSMaxY(windowFrame) - 
newWindowHeight,
                       NSWidth(windowFrame),
                       newWindowHeight),
            self.window().styleMask())
        self.window().setContentView_(pane)
        
self.window().setFrame_display_animate_(newWindowFra
me,
                                                YES,
                                                
self.window().isVisible())

**********

Host:       gorilla.urbanape.com
Date/Time:  2003-11-04 22:52:17 -0500
OS Version: 10.3 (Build 7B85)

Command:    python (/Users/zbir/Applications/
ZopeEditManager.app/Contents/MacOS/python)
PID:        613
Thread:     0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 
0x0000000c

Thread 0 Crashed:
 #0   0x90831388 in objc_msgSend_stret 
(objc_msgSend_stret + 8)
 #1   0x92dcff08 in -[NSWindow contentRectForFrameRect:
styleMask:] (-[NSWindow contentRectForFrameRect:
styleMask:] + 160)
 #2   0x00428974 in ffi_call_DARWIN (ffi_call_DARWIN + 
208)
 #3   0x00428368 in ffi_call (ffi_darwin.c:401)
 #4   0x00426f08 in ObjC_FFICaller (libffi_support.m:1088)
 #5   0x0041a12c in objcsel_call (selector.m:594)
 #6   0x95f4a8d0 in PyObject_Call (PyObject_Call + 48)
 #7   0x95fa9ba8 in PyEval_GetFuncDesc 
(PyEval_GetFuncDesc + 2268)
 #8   0x95fa9598 in PyEval_GetFuncDesc 
(PyEval_GetFuncDesc + 716)
 #9   0x95fa6c64 in PyEval_EvalCode (PyEval_EvalCode + 
9568)
 #10  0x95fa7e30 in PyEval_EvalCodeEx 
(PyEval_EvalCodeEx + 2128)
 #11  0x95f5f354 in PyFunction_SetClosure 
(PyFunction_SetClosure + 3436)
 #12  0x95f4a8d0 in PyObject_Call (PyObject_Call + 48)
 #13  0x0041b13c in pysel_call (selector.m:997)
 #14  0x95f4a8d0 in PyObject_Call (PyObject_Call + 48)
 #15  0x95fa9ba8 in PyEval_GetFuncDesc 
(PyEval_GetFuncDesc + 2268)
 #16  0x95fa9598 in PyEval_GetFuncDesc 
(PyEval_GetFuncDesc + 716)
 #17  0x95fa6c64 in PyEval_EvalCode (PyEval_EvalCode + 
9568)
 #18  0x95fa7e30 in PyEval_EvalCodeEx 
(PyEval_EvalCodeEx + 2128)
 #19  0x95f5f354 in PyFunction_SetClosure 
(PyFunction_SetClosure + 3436)
 #20  0x95f4a8d0 in PyObject_Call (PyObject_Call + 48)
 #21  0x0041b13c in pysel_call (selector.m:997)
 #22  0x95f4a8d0 in PyObject_Call (PyObject_Call + 48)
 #23  0x95fa9ba8 in PyEval_GetFuncDesc 
(PyEval_GetFuncDesc + 2268)
 #24  0x95fa9598 in PyEval_GetFuncDesc 
(PyEval_GetFuncDesc + 716)
 #25  0x95fa6c64 in PyEval_EvalCode (PyEval_EvalCode + 
9568)
 #26  0x95fa7e30 in PyEval_EvalCodeEx 
(PyEval_EvalCodeEx + 2128)
 #27  0x95f5f354 in PyFunction_SetClosure 
(PyFunction_SetClosure + 3436)
 #28  0x95f4a8d0 in PyObject_Call (PyObject_Call + 48)
 #29  0x0041b024 in pysel_call (selector.m:979)
 #30  0x95f4a8d0 in PyObject_Call (PyObject_Call + 48)
 #31  0x004104ac in PyObjC_CallPython (class-builder.m:
1410)
 #32  0x0042524c in method_stub (libffi_support.m:416)
 #33  0x004286ac in ffi_closure_helper_DARWIN 
(ffi_darwin.c:699)
 #34  0x00428a44 in ffi_closure_ASM (ffi_closure_ASM + 
116)
 #35  0x92df240c in -[NSIBObjectData 
nibInstantiateWithOwner:topLevelObjects:] (-
[NSIBObjectData nibInstantiateWithOwner:
topLevelObjects:] + 920)
 #36  0x92ee3ab4 in loadNib (loadNib + 252)
 #37  0x92e3ae64 in +[NSBundle(NSNibLoading) 
_loadNibFile:nameTable:withZone:ownerBundle:] 
(+[NSBundle(NSNibLoading) _loadNibFile:nameTable:
withZone:ownerBundle:] + 744)
 #38  0x92eb9b58 in +[NSBundle(NSNibLoading) 
loadNibFile:externalNameTable:withZone:] 
(+[NSBundle(NSNibLoading) loadNibFile:
externalNameTable:withZone:] + 156)
 #39  0x92ec095c in -[NSWindowController loadWindow] (-
[NSWindowController loadWindow] + 204)
 #40  0x92e75128 in -[NSWindowController window] (-
[NSWindowController window] + 92)
 #41  0x92f31adc in -[NSWindowController showWindow:] 
(-[NSWindowController showWindow:] + 36)
 #42  0x00428974 in ffi_call_DARWIN (ffi_call_DARWIN + 
208)
 #43  0x00428368 in ffi_call (ffi_darwin.c:401)
 #44  0x00426f2c in ObjC_FFICaller (libffi_support.m:
1097)
 #45  0x0041a010 in objcsel_call (selector.m:575)
 #46  0x95f4a8d0 in PyObject_Call (PyObject_Call + 48)
 #47  0x95fa9ba8 in PyEval_GetFuncDesc 
(PyEval_GetFuncDesc + 2268)
 #48  0x95fa9598 in PyEval_GetFuncDesc 
(PyEval_GetFuncDesc + 716)
 #49  0x95fa6c64 in PyEval_EvalCode (PyEval_EvalCode + 
9568)
 #50  0x95fa7e30 in PyEval_EvalCodeEx 
(PyEval_EvalCodeEx + 2128)
 #51  0x95f5f354 in PyFunction_SetClosure 
(PyFunction_SetClosure + 3436)
 #52  0x95f4a8d0 in PyObject_Call (PyObject_Call + 48)
 #53  0x0041b024 in pysel_call (selector.m:979)
 #54  0x95f4a8d0 in PyObject_Call (PyObject_Call + 48)
 #55  0x004104ac in PyObjC_CallPython (class-builder.m:
1410)
 #56  0x0042524c in method_stub (libffi_support.m:416)
 #57  0x004286ac in ffi_closure_helper_DARWIN 
(ffi_darwin.c:699)
 #58  0x00428a44 in ffi_closure_ASM (ffi_closure_ASM + 
116)
 #59  0x92e779d0 in -[NSApplication sendAction:to:from:] 
(-[NSApplication sendAction:to:from:] + 108)
 #60  0x92ead1bc in -[NSMenu 
performActionForItemAtIndex:] (-[NSMenu 
performActionForItemAtIndex:] + 392)
 #61  0x92ef1ac4 in -[NSCarbonMenuImpl 
performActionWithHighlightingForItemAtIndex:] (-
[NSCarbonMenuImpl 
performActionWithHighlightingForItemAtIndex:] + 104)
 #62  0x92ef83f4 in -[NSMenu performKeyEquivalent:] (-
[NSMenu performKeyEquivalent:] + 260)
 #63  0x92ed7420 in -[NSApplication 
_handleKeyEquivalent:] (-[NSApplication 
_handleKeyEquivalent:] + 292)
 #64  0x92df4eec in -[NSApplication sendEvent:] (-
[NSApplication sendEvent:] + 2652)
 #65  0x92dfd754 in -[NSApplication run] (-[NSApplication 
run] + 576)
 #66  0x92eb9a1c in NSApplicationMain (NSApplicationMain 
+ 464)
 #67  0x006beda8 in objc_NSApplicationMain (_AppKit.m:
116)
 #68  0x95fa94a8 in PyEval_GetFuncDesc 
(PyEval_GetFuncDesc + 476)
 #69  0x95fa6c64 in PyEval_EvalCode (PyEval_EvalCode + 
9568)
 #70  0x95fa7e30 in PyEval_EvalCodeEx 
(PyEval_EvalCodeEx + 2128)
 #71  0x95fa97dc in PyEval_GetFuncDesc 
(PyEval_GetFuncDesc + 1296)
 #72  0x95fa9580 in PyEval_GetFuncDesc 
(PyEval_GetFuncDesc + 692)
 #73  0x95fa6c64 in PyEval_EvalCode (PyEval_EvalCode + 
9568)
 #74  0x95fa7e30 in PyEval_EvalCodeEx 
(PyEval_EvalCodeEx + 2128)
 #75  0x95fa4734 in PyEval_EvalCode (PyEval_EvalCode + 
48)
 #76  0x95fc85f0 in PyRun_FileExFlags (PyRun_FileExFlags 
+ 228)
 #77  0x95fc7668 in PyRun_SimpleFileExFlags 
(PyRun_SimpleFileExFlags + 444)
 #78  0x95fd1ec0 in Py_Main (Py_Main + 1996)
 #79  0x00003c78 in start (start + 444)
 #80  0x00003aec in start (start + 48)

PPC Thread State:
  srr0: 0x90831388 srr1: 0x0200f030                vrsave: 
0x00000000
    cr: 0x40224242  xer: 0x20000004   lr: 0x92dcff08  ctr: 
0x90831380
    r0: 0x92dcff08   r1: 0xbfffa150   r2: 0xa2dc1535   r3: 
0xbfffa190
    r4: 0x0000000c   r5: 0x9086ee4c   r6: 0x42200000   r7: 
0x443cc000
    r8: 0x43c80000   r9: 0x42a60000  r10: 0x00000003  
r11: 0xa2dc1fb4
   r12: 0x90831380  r13: 0x0123d060  r14: 0x00000000  
r15: 0x00791558
   r16: 0x00000000  r17: 0x00000000  r18: 0x00000000  
r19: 0x00000000
   r20: 0x00000000  r21: 0x003054c0  r22: 0x00000003  
r23: 0x0037412e
   r24: 0xbfffaf2c  r25: 0x00366f84  r26: 0x00000000  r27: 
0x01148920
   r28: 0x00000003  r29: 0xa2dfce3c  r30: 0xbfffa1e4  r31: 
0x92dcfe68

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

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

Re: [Pyobjc-dev] ScreenSaver Example

[Jason T. <cat...@ma...>]

Well I tried that with the screensaver, and I get this error with 
pyobjc from CVS.

loading python screen saver
2003-11-04 15:51:52.369 System Preferences[9755] *** 
-[_PyObjC_BundleHelper_SillyBalls_ initWithFrame:isPreview:]: selector 
not recognized

And with the released pyobjc 1.0, it was just crashing on me after the 
loading line.

Here is a copy of my pyobjc screen saver without a nib.
http://illadvised.com/~jason/SillyBallsSaverNoNib.zip

FYI: I found several ObjC screensaver projects which use Xcode/Project 
Builder that have no principleClass set. Not sure if that would make 
any difference, but ScreenSaver bundles don't seem to be like prefPane 
bundles in that you don't need to set the principleClass.

Thanks,
- Jason T.

On Nov 4, 2003, at 2:15 PM, Ronald Oussoren wrote:

>
> On 4 nov 2003, at 20:23, Jason Toffaletti wrote:
>
>> The first error message "can't get principalClass for 
>> /Users/dinu/Library/Screen Savers/SillyBalls.saver" actually brings 
>> up an issue I had when creating the screensaver, because I was trying 
>> to get around using a nib file by specifying a principleClass. At the 
>> time it seemed like that should work...So, I am wondering if it is 
>> possible to get rid of the requirement of having to specify a nib 
>> file? I was told that Ronald would have something to say about this.
>
> I wouldn't know why you couldn't get rid of the NIB file. You'd have 
> to inherit your principleClass from the right superclass (not 
> AutoBaseClass, but a real Objective-C class), but that should be it.
>
> Ronald
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] ScreenSaver Example

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

On 4 nov 2003, at 20:23, Jason Toffaletti wrote:

> The first error message "can't get principalClass for 
> /Users/dinu/Library/Screen Savers/SillyBalls.saver" actually brings up 
> an issue I had when creating the screensaver, because I was trying to 
> get around using a nib file by specifying a principleClass. At the 
> time it seemed like that should work...So, I am wondering if it is 
> possible to get rid of the requirement of having to specify a nib 
> file? I was told that Ronald would have something to say about this.

I wouldn't know why you couldn't get rid of the NIB file. You'd have to 
inherit your principleClass from the right superclass (not 
AutoBaseClass, but a real Objective-C class), but that should be it.

Ronald

Re: [Pyobjc-dev] Re: Structs, tuples and instances

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

On 4 nov 2003, at 21:26, Bob Ippolito wrote:
>
> Personally, I'd like to see how these structseq's work out (anxiously 
> waiting for a commit from Ronald!).

That might take a while, the patch for python's structseq 
implementation is as far as I got.

> Sounds like it might even be possible to use a more generic 
> implementation as a general (and higher perforamance?) replacement for 
> the struct module, at least when you're working in machine endian.  
> For example, it would be a lot more elegant to use structseq to read 
> mach-o headers, and try and rig the PyObjC generator scripts to 
> autogenerate structseq definitions for me.. right now the mach-o 
> structures are coded by hand by looking at structures in C header 
> files as a reference and I am using a module I wrote called ptypes 
> which does something similar (interface wise) to ctypes structures and 
> base types, but ends up having to use the Python struct module to do 
> the actual en/decoding (which is kinda wasteful and awkward).

Structseqs as currently used by Python are just a tuple with named 
attributes that alias (some of) the items in the tuple, they cannot be 
used as a replacement for the struct module. My current idea for 
mutable structseqs in PyObjC is to use the same strategy, possibly 
enhanced with typechecking. The type-generator function will be exposed 
to Python.

I could easily expose the functions for encoding/decoding Objective-C 
types to Python, which would help in creating a replacement for ptypes.

Ronald

Re: [Pyobjc-dev] Re: Structs, tuples and instances

[Bob I. <bo...@re...>]

On Nov 4, 2003, at 5:45 AM, Dinu Gherman wrote:

> Ronald Oussoren:
>
>> I agree that immutability isn't very usefull, but it buys you one
>> important feature: structseqs are useable as keys in dictionaries.
>
> How much is that worth when dealing with elements which actually
> *are* and *should be* mutable?
>
>> Does anyone use points, rects or sizes as the key in a dictionary?
>
> My point of view is that doing this is a *bad idea* and the fact
> that you can do it now introduces a source of confusion because
> it advocates usage patterns in PyObjC which are not just some
> kind of a more Pythonic way of doing something, but introduce
> artificial and unnecessary differences between PyObjC and ObjC
> on a conceptual level, which must be something to minimize if
> technically possible.

I'm with Dinu on this.  Although most of the structs passed around in 
ObjC seem to be passed by value and not by reference.. I'd still say 
that they're all mutable.  If they want something immutable they can do 
tuple(structSeqObj) or some other kind of copy.  I've never seen 
NSPoint, NSRect, etc. used as a dictionary key from PyObjC... in 
Objective C you can't even (directly) put them in any kind of 
collection b/c they are plain 'ol C structs so I don't see where anyone 
would get the idea to do it in Python.

Personally, I'd like to see how these structseq's work out (anxiously 
waiting for a commit from Ronald!).  Sounds like it might even be 
possible to use a more generic implementation as a general (and higher 
perforamance?) replacement for the struct module, at least when you're 
working in machine endian.  For example, it would be a lot more elegant 
to use structseq to read mach-o headers, and try and rig the PyObjC 
generator scripts to autogenerate structseq definitions for me.. right 
now the mach-o structures are coded by hand by looking at structures in 
C header files as a reference and I am using a module I wrote called 
ptypes which does something similar (interface wise) to ctypes 
structures and base types, but ends up having to use the Python struct 
module to do the actual en/decoding (which is kinda wasteful and 
awkward).

-bob

Re: [Pyobjc-dev] ScreenSaver Example

[Jason T. <cat...@ma...>]

The first error message "can't get principalClass for 
/Users/dinu/Library/Screen Savers/SillyBalls.saver" actually brings up 
an issue I had when creating the screensaver, because I was trying to 
get around using a nib file by specifying a principleClass. At the time 
it seemed like that should work...So, I am wondering if it is possible 
to get rid of the requirement of having to specify a nib file? I was 
told that Ronald would have something to say about this.

Thanks,
Jason T.

> On Nov 4, 2003, at 2:33 AM, Dinu Gherman wrote:
>
>> Ronald Oussoren:
>>
>>> It works for me (TM). There's a buildplugin.py script in the 
>>> archive, run 'buildplugin build' and then 'open 
>>> build/SillyBalls.saver'. On Panther you'll get a message that the 
>>> saver should be installed first, and System Preferences will install 
>>> it for you. I don't know if this works on Jaguar, you may have to 
>>> install it manually (in ~/Library/Screen Savers).
>>
>> Ok, I've built it as you say, moved it into ~/Library/Screen Savers 
>> and
>> get this when trying to select it on 10.2.8 (with PyObjC 1.0) from 
>> System
>> Preferences:
>>
>>   Failed to initialize bundle NSBundle </Users/dinu/Library/
>>   Screen Savers/SillyBalls.saver> (loaded)
>>
>> The console says the following:
>>
>> 2003-11-04 11:27:00.027 System Preferences[2254] can't get 
>> principalClass for /Users/dinu/Library/Screen Savers/SillyBalls.saver
>> loading python screen saver
>> Traceback (most recent call last):
>>   File "/Users/dinu/Library/Screen 
>> Savers/SillyBalls.saver/Contents/Resources/SillyBalls.py", line 6, in 
>> ?
>>     from AppKit import NSMakePoint, NSMakeRect, NSBezierPath, NSColor
>> ImportError: No module named AppKit
>>
>> Is the above a general problem with bundles that has been solved for
>> 10.3 or is the lower part just a bug?
>>
>> Dinu
>>
>> --
>> Dinu C. Gherman - http://python.net/~gherman
>> ......................................................................
>> "The best way to predict the future is to invent it." (Alan Kay)
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: SF.net Giveback Program.
>> Does SourceForge.net help you be more productive?  Does it
>> help you create better code?   SHARE THE LOVE, and help us help
>> YOU!  Click Here: http://sourceforge.net/donate/
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] ScreenSaver Example

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

On 4 nov 2003, at 12:02, Dinu Gherman wrote:

> Ronald Oussoren:
>
>> Did you use MacPython? You must use MacPython (or another framework
>> install) to use Python based screensavers (and other plugin bundles).
>
> No I didn't... Why not? Well... versionitis! I'm increasingly
> concerned about the raising number of versioning knobs in the
> Mac-Python (Python-Mac?) world...

I agree that there's a confusingly large number of Python's on the Mac, 
but if you leave out the portmanager (fink, darwinports, ...) things 
get a lot more manageable :-)

The current situation seems to be:
1. /usr/bin/python (2.2) on Jaguar
2. MacPython 2.3 on Jaguar
3. /usr/bin/python (2.3) on Panther
4,5,... {Fink,DarwinPorts,...} python 2.[23] on {Panther, Jaguar}
N. MacPython 2.3 for OS9 (Classic). This can be ignored unless you use 
OS9 or use OS9-style libraries.

MacPython 2.3 for Panther contains nothing more than the GUI tools and 
the waste library.

I currently use MacPython-2.3 on Jaguar (with /usr/local/bin before 
/usr/bin in my PATH) and Apple's Python on Panther. The only reason for 
using /usr/bin/python on Jaguar is the development of scripts that 
should run on customer systems.

Ronald

[Pyobjc-dev] Regarding: www.gnustep.org/

[<re...@gl...>]

Hello,

This e-mail has been sent to inform you that your 
web site URL has been submitted to our search engine
database. This is the URL that will be added.

    URL : www.gnustep.org/
   DATE : 11/4/2003 8:5:16
IP ADDR : Unknown IP. User had used an automated software for url submission

In order to complete this request we require that you 
click on the web site link below. This will confirm
that you do wish to be added to our search engine.

http://www.global-submit.com/confirm.cgi?T885365R746775

If you feel that you received this message in error
or you did not have your web site submitted to our
search engine, please click on the link below. We 
will make every effort to make sure that you are 
no longer bothered by this automated system. 

http://www.global-submit.com/clipout.cgi?T885365R746775

Thank you and please have a nice day

Global-Submit.com tech Staff
www.global-submit.com
1 819 571 4943

Re: [Pyobjc-dev] ScreenSaver Example

[Dinu G. <gh...@da...>]

Ronald Oussoren:

> Did you use MacPython? You must use MacPython (or another framework
> install) to use Python based screensavers (and other plugin bundles).

No I didn't... Why not? Well... versionitis! I'm increasingly
concerned about the raising number of versioning knobs in the
Mac-Python (Python-Mac?) world...

I'll retry later after installing Panther, after making sure
the FireWire issue doesn't exist for me...

Dinu

--
Dinu C. Gherman - http://python.net/~gherman
......................................................................
"The first principle is that you must not fool yourself - and you are
the easiest person to fool." (Richard Feynman)

Re: [Pyobjc-dev] Re: Structs, tuples and instances

[Dinu G. <gh...@da...>]

Ronald Oussoren:

> I agree that immutability isn't very usefull, but it buys you one
> important feature: structseqs are useable as keys in dictionaries.

How much is that worth when dealing with elements which actually
*are* and *should be* mutable?

> Does anyone use points, rects or sizes as the key in a dictionary?

My point of view is that doing this is a *bad idea* and the fact
that you can do it now introduces a source of confusion because
it advocates usage patterns in PyObjC which are not just some
kind of a more Pythonic way of doing something, but introduce
artificial and unnecessary differences between PyObjC and ObjC
on a conceptual level, which must be something to minimize if
technically possible.

Dinu

--
Dinu C. Gherman - http://python.net/~gherman
......................................................................
"The whole point of brainwashing, is that those being brainwashed
don't know it." (Graham Haley)

Re: [Pyobjc-dev] ScreenSaver Example

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

On 4 nov 2003, at 11:33, Dinu Gherman wrote:
>
> The console says the following:
>
> 2003-11-04 11:27:00.027 System Preferences[2254] can't get 
> principalClass for /Users/dinu/Library/Screen Savers/SillyBalls.saver
> loading python screen saver
> Traceback (most recent call last):
>   File "/Users/dinu/Library/Screen 
> Savers/SillyBalls.saver/Contents/Resources/SillyBalls.py", line 6, in 
> ?
>     from AppKit import NSMakePoint, NSMakeRect, NSBezierPath, NSColor
> ImportError: No module named AppKit
>
> Is the above a general problem with bundles that has been solved for
> 10.3 or is the lower part just a bug?

Did you use MacPython? You must use MacPython (or another framework 
install) to use Python based screensavers (and other plugin bundles).

Ronald

Re: [Pyobjc-dev] Re: Structs, tuples and instances

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

On 4 nov 2003, at 11:29, Just van Rossum wrote:

> Ronald Oussoren wrote:
>
>> The patch for Python is easy enough, but there is one major downside
>> of this patch: writeable structseqs are not hashable, which makes it
>> impossible to use these objects as keys in dictionaries. Making them
>> hashable would be easy, it would even decrease the size of the patch,
>> but would make it possible to create invalid dicts:
>
> Under *no* circumstance this should be possible. If an object is
> hashable, it should be immutable. If this is not true, you're breaking 
> a
> major dict invariant and you can't blame the user if things go wrong.

+1

>
> For the same reason I think that pyobjc_unicode.syncFromNSString() is 
> an
> extremely bad idea and should be removed. It's not even needed: if you
> work with an NSMutableString that actually mutates, you can get the
> up-to-date Python value with unicode(aMutableString.nsstring()).

You've got a point. I'll add a deprication warning to syncFromNSString, 
and remove the method after the next release of PyObjC.  I'd be 
surprised if anyone uses this method, maybe we can get away with 
removing it before the next release.

Ronald

Re: [Pyobjc-dev] ScreenSaver Example

[Dinu G. <gh...@da...>]

Ronald Oussoren:

> It works for me (TM). There's a buildplugin.py script in the archive, 
> run 'buildplugin build' and then 'open build/SillyBalls.saver'. On 
> Panther you'll get a message that the saver should be installed first, 
> and System Preferences will install it for you. I don't know if this 
> works on Jaguar, you may have to install it manually (in 
> ~/Library/Screen Savers).

Ok, I've built it as you say, moved it into ~/Library/Screen Savers and
get this when trying to select it on 10.2.8 (with PyObjC 1.0) from 
System
Preferences:

   Failed to initialize bundle NSBundle </Users/dinu/Library/
   Screen Savers/SillyBalls.saver> (loaded)

The console says the following:

2003-11-04 11:27:00.027 System Preferences[2254] can't get 
principalClass for /Users/dinu/Library/Screen Savers/SillyBalls.saver
loading python screen saver
Traceback (most recent call last):
   File "/Users/dinu/Library/Screen 
Savers/SillyBalls.saver/Contents/Resources/SillyBalls.py", line 6, in ?
     from AppKit import NSMakePoint, NSMakeRect, NSBezierPath, NSColor
ImportError: No module named AppKit

Is the above a general problem with bundles that has been solved for
10.3 or is the lower part just a bug?

Dinu

--
Dinu C. Gherman - http://python.net/~gherman
......................................................................
"The best way to predict the future is to invent it." (Alan Kay)

Re: [Pyobjc-dev] Re: Structs, tuples and instances

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

On 4 nov 2003, at 11:09, Dinu Gherman wrote:

> Ronald Oussoren:
>
>> The patch for Python is easy enough, but there is one major downside 
>> of this patch: writeable structseqs are not hashable, which makes it 
>> impossible to use these objects as keys in dictionaries. Making them 
>> hashable would be easy, it would even decrease the size of the patch, 
>> but would make it possible to create invalid dicts:
>
> I'm not sure why anybody would expect things like NSPoints, NSRects
> and NSSizes to be immutable? Being tuples in PyObjC adds a feature
> which has no equivalent in ObjC, isn't it? In fact, it prevents you
> from doing even point[0] = 1 not to mention point.x = 1...

Tuples are commonly used to represent C-structs in Python. That is the 
only reason for using tuples to represent NSPoint as a tuple. As 
several people noticed,  myrect[0][1] is a lot less readable than 
myrect.location.x, which is why structseq's would be usefull.

Structseqs are backward compatible with tuples, and therefore 
immutable. I agree that immutability isn't very usefull, but it buys 
you one important feature: structseqs are useable as keys in 
dictionaries. Mutable structseqs would not be useable as dictionary 
keys, because such objects would not have a constant hash (and 
therefore should be unhashable)

Does anyone use points, rects or sizes as the key in a dictionary? If 
not, we could change the representation of NSPoint, etc., to mutable 
structseq's (with a prominent notice in the release-notes for the next 
release, as this is a backward incompatible change).

We could also add a hash function to mutable structseqs, with a note in 
the documentation that you shouldn't modify a mutable structseq object 
that is used as the key in a dictionary. None of the mutable types in 
the Python distribution seems to do this.

Ronald

Re: [Pyobjc-dev] Re: Structs, tuples and instances

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

Ronald Oussoren wrote:

> The patch for Python is easy enough, but there is one major downside
> of this patch: writeable structseqs are not hashable, which makes it
> impossible to use these objects as keys in dictionaries. Making them
> hashable would be easy, it would even decrease the size of the patch,
> but would make it possible to create invalid dicts:

Under *no* circumstance this should be possible. If an object is
hashable, it should be immutable. If this is not true, you're breaking a
major dict invariant and you can't blame the user if things go wrong.

For the same reason I think that pyobjc_unicode.syncFromNSString() is an
extremely bad idea and should be removed. It's not even needed: if you
work with an NSMutableString that actually mutates, you can get the
up-to-date Python value with unicode(aMutableString.nsstring()).

Just

Re: [Pyobjc-dev] ScreenSaver Example

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

On 4 nov 2003, at 11:00, Dinu Gherman wrote:

> Jason Toffaletti:
>
>> Hello everyone, I just joined the mailing list so I can hopefully 
>> become involved in the development of PyObjC. I am fairly new to 
>> Python, but it is already my language of choice. I put together an 
>> example screensaver in PyObjC, which I hope can be included with the 
>> rest of the Examples. 
>> http://illadvised.com/~jason/SillyBallsSaver.zip
>
> Interesting! I've written screensavers before in ObjC, so I'm
> interested in this one, but I can't get it to work. Could you
> explain, please, what's needed to make it run?

It works for me (TM). There's a buildplugin.py script in the archive, 
run 'buildplugin build' and then 'open build/SillyBalls.saver'. On 
Panther you'll get a message that the saver should be installed first, 
and System Preferences will install it for you. I don't know if this 
works on Jaguar, you may have to install it manually (in 
~/Library/Screen Savers).

Ronald

Re: [Pyobjc-dev] Re: Structs, tuples and instances

[Dinu G. <gh...@da...>]

Ronald Oussoren:

> The patch for Python is easy enough, but there is one major downside 
> of this patch: writeable structseqs are not hashable, which makes it 
> impossible to use these objects as keys in dictionaries. Making them 
> hashable would be easy, it would even decrease the size of the patch, 
> but would make it possible to create invalid dicts:

I'm not sure why anybody would expect things like NSPoints, NSRects
and NSSizes to be immutable? Being tuples in PyObjC adds a feature
which has no equivalent in ObjC, isn't it? In fact, it prevents you
from doing even point[0] = 1 not to mention point.x = 1...

Perhaps immutability makes sense for other structs? I don't know
of such examples, but maybe others do?

Dinu

--
Dinu C. Gherman - http://python.net/~gherman
......................................................................
"There are causes worth dying for, but none worth killing for."
(Albert Camus)

Re: [Pyobjc-dev] ScreenSaver Example

[Dinu G. <gh...@da...>]

Jason Toffaletti:

> Hello everyone, I just joined the mailing list so I can hopefully 
> become involved in the development of PyObjC. I am fairly new to 
> Python, but it is already my language of choice. I put together an 
> example screensaver in PyObjC, which I hope can be included with the 
> rest of the Examples. http://illadvised.com/~jason/SillyBallsSaver.zip

Interesting! I've written screensavers before in ObjC, so I'm
interested in this one, but I can't get it to work. Could you
explain, please, what's needed to make it run?

In fact, I'd like to port my TimeCycler screensaver (which is
also available as PyObjC Desktop standalone) fully to Python,
see also: http://python.net/~gherman/TimeCycler.html

Thanks,

Dinu

--
Dinu C. Gherman - http://python.net/~gherman
......................................................................
"They made a desert and called it peace." (Tacitus)

Re: [Pyobjc-dev] ScreenSaver Example

[Bob I. <bo...@re...>]

On Nov 3, 2003, at 2:01 PM, Jason Toffaletti wrote:

> Hello everyone, I just joined the mailing list so I can hopefully 
> become involved in the development of PyObjC. I am fairly new to 
> Python, but it is already my language of choice. I put together an 
> example screensaver in PyObjC, which I hope can be included with the 
> rest of the Examples. http://illadvised.com/~jason/SillyBallsSaver.zip
>
> I am willing to work on anything that needs to get done, even writing 
> documentation. Just point me in the right direction.

Welcome!

Documentation is awesome, we love documentation (other than writing 
it).  I'm not aware of anything in the core that needs work, other than 
some gritty stuff on the insides and GNUStep support (Ronald is our 
hero).  However, documentation, examples, and evangelism are all more 
than welcome.

Of course, if you bind any bugs, report them to the sourceforge.net 
bugtracker.  If you'd like a quick way to write documentation, feel 
free to use the pythonmac.org wiki:
	http://pythonmac.org/wiki (and http://pythonmac.org/wiki/PyObjC )

Also, the LettError wiki has a really nice entry related to PyObjC:
	http://just.letterror.com/ltrwiki/StartCocoa

Would you like your screen saver to be included in the next version of 
PyObjC as an example?

-bob

[Pyobjc-dev] ScreenSaver Example

[Jason T. <cat...@ma...>]

Hello everyone, I just joined the mailing list so I can hopefully 
become involved in the development of PyObjC. I am fairly new to 
Python, but it is already my language of choice. I put together an 
example screensaver in PyObjC, which I hope can be included with the 
rest of the Examples. http://illadvised.com/~jason/SillyBallsSaver.zip

I am willing to work on anything that needs to get done, even writing 
documentation. Just point me in the right direction.

- Jason T.

[Pyobjc-dev] Regarding: www.gnustep.org/

[<pr...@gl...>]

You are receiving this e-mail because you were added to
http://www.global-submit.com in the past. Here is the URL
that was submitted to our search engine database.
http://www.gnustep.org/





RMV MESSAGE ID : T885365R746775

If would like to be taken out of our database then please visit this web site.
http://www.global-submit.com/cgi-bin/clipout.cgi?T885365R746775

Re: [Pyobjc-dev] Re: Structs, tuples and instances

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

On 31 okt 2003, at 18:07, Ronald Oussoren wrote:
>>> I'd love that... As I said I could put it to good use for the 
>>> various Mac toolbox objects.
>
> But such a patch would not be useable by PyObjC until Python 2.4 gets 
> out :-(. That said, I'll work on such a patch. I will also work on a 
> custom version for PyObjC ;-).
>
The patch for Python is easy enough, but there is one major downside of 
this patch: writeable structseqs are not hashable, which makes it 
impossible to use these objects as keys in dictionaries. Making them 
hashable would be easy, it would even decrease the size of the patch, 
but would make it possible to create invalid dicts:
	
	d = {}
	p = NSPoint(x=1, y=2)
	d[p] = 1
	p.x = 3

d[d.keys()[0]] will fail, as will d[NSPoint(x=3, y=2)] unless 
NSPoint(1,2) happens to have the same hash as NSPoint(3,2).

A completely untested patch is included below, I haven't even tried to 
compile this.

Ronald

Index: Include/structseq.h
===================================================================
RCS file: /cvsroot/python/python/dist/src/Include/structseq.h,v
retrieving revision 1.4
diff -c -r1.4 structseq.h
*** Include/structseq.h	17 Oct 2002 19:48:27 -0000	1.4
--- Include/structseq.h	3 Nov 2003 15:39:46 -0000
***************
*** 23,28 ****
--- 23,30 ----

   PyAPI_FUNC(void) PyStructSequence_InitType(PyTypeObject *type,
   					   PyStructSequence_Desc *desc);
+ PyAPI_FUNC(void) PyStructSequence_InitTypeRW(PyTypeObject *type,
+ 					   PyStructSequence_Desc *desc);

   PyAPI_FUNC(PyObject *) PyStructSequence_New(PyTypeObject* type);

Index: Objects/structseq.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/structseq.c,v
retrieving revision 1.12
diff -c -r1.12 structseq.c
*** Objects/structseq.c	1 Feb 2003 02:16:37 -0000	1.12
--- Objects/structseq.c	3 Nov 2003 15:39:47 -0000
***************
*** 342,349 ****
   	structseq_new,				/* tp_new */
   };

! void
! PyStructSequence_InitType(PyTypeObject *type, PyStructSequence_Desc 
*desc)
   {
   	PyObject *dict;
   	PyMemberDef* members;
--- 342,349 ----
   	structseq_new,				/* tp_new */
   };

! static void
! _inittype(PyTypeObject* type, PyStructSequence_Desc* desc, int 
readWrite)
   {
   	PyObject *dict;
   	PyMemberDef* members;
***************
*** 373,384 ****
   		members[k].type = T_OBJECT;
   		members[k].offset = offsetof(PyStructSequence, ob_item)
   		  + i * sizeof(PyObject*);
! 		members[k].flags = READONLY;
   		members[k].doc = desc->fields[i].doc;
   		k++;
   	}
   	members[k].name = NULL;

   	type->tp_members = members;

   	if (PyType_Ready(type) < 0)
--- 373,393 ----
   		members[k].type = T_OBJECT;
   		members[k].offset = offsetof(PyStructSequence, ob_item)
   		  + i * sizeof(PyObject*);
!
! 		if (readWrite) {
! 			members[k].flags = 0;
! 		} else {
! 			members[k].flags = READONLY;
! 		}
   		members[k].doc = desc->fields[i].doc;
   		k++;
   	}
   	members[k].name = NULL;

+ 	if (readWrite) {
+ 		type->tp_hash = NULL;
+ 	}
+
   	type->tp_members = members;

   	if (PyType_Ready(type) < 0)
***************
*** 392,395 ****
--- 401,416 ----
   		       PyInt_FromLong((long) n_members));
   	PyDict_SetItemString(dict, unnamed_fields_key,
   		       PyInt_FromLong((long) n_unnamed_members));
+ }
+
+ void
+ PyStructSequence_InitType(PyTypeObject *type, PyStructSequence_Desc 
*desc)
+ {
+ 	_inittype(type, desc, 0);
+ }
+
+ void
+ PyStructSequence_InitTypeRW(PyTypeObject *type, PyStructSequence_Desc 
*desc)
+ {
+ 	_inittype(type, desc, 1);
   }

Re: [Pyobjc-dev] No need to migrate list?

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

On 30 okt 2003, at 19:40, Just van Rossum wrote:

> Zachery Bir wrote:
>
>>> See also
>>> https://sourceforge.net/tracker/?
>>> func=detail&atid=200001&aid=828759&group_id=1
>>
>> Does this change anyone's preference for list migration?
>>
>> Just checking.
>
> Well, if it works ok now, why bother?

I agree, let's not move the list.

Ronald

Re: [Pyobjc-dev] Re: Structs, tuples and instances

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

On 31 okt 2003, at 17:30, Bob Ippolito wrote:

>
> On Oct 31, 2003, at 11:19 AM, Jack Jansen wrote:
>
>>
>> On 31 Oct 2003, at 15:14, Michael Hudson wrote:
>>
>>> Ronald Oussoren <ous...@ci...> writes:
>>>
>>>> On 31 okt 2003, at 11:54, Jack Jansen wrote:
>>>>
>>>>> Hmm, even if it isn't available from Python the objc core could 
>>>>> make
>>>>> it available. Using structmember for the various toolbox structures
>>>>> is something that's also on my to-do list, but I haven't done
>>>>> anything about it yet so I don't know how feasible this approach 
>>>>> is.
>>>>
>>>> Do you mean the new PyStructSequence_Type as used by os.stat and
>>>> time.localtime?
>>>
>>> Ah, that would be more likely than what he actually said :-)
>>
>> Right:-)
>>
>>>> Those "structures" are (sadly) read-only. I'm thinking of ...
>>>
>>> If you do do something about this, it might be worth offering a patch
>>> to Python itself; tcgetattr at least could use such functionality.
>>
>> I'd love that... As I said I could put it to good use for the various 
>> Mac toolbox objects.

But such a patch would not be useable by PyObjC until Python 2.4 gets 
out :-(. That said, I'll work on such a patch. I will also work on a 
custom version for PyObjC ;-).

>
> While you're thinking about Mac toolbox objects, how about making 
> FSSpec / FSRef / FSAlias easier to use?  Personally, I think it would 
> be killer if I could str(fsSpec) and get the utf8 path out of it (or 
> unicode(fsSpec) and get the unicode path out of it).
>
> Thinking aloud here, I'm really liking the signatures.  It allows me 
> to fix PyObjC methods without recompiling (if I want to), and they're 
> pretty easy to understand (after looking at a lot of them).  I wish 
> bgen wrapped modules had this kind of capability (but then we'd almost 
> have ctypes).

But the signatures are used only because they are easily available at 
runtime and the implementation for all methods is basically the same. 
If you want to do the same for other frameworks/libararies you'd not 
*almost* have ctypes, but basically all of it.

Ronald

Re: [Pyobjc-dev] Re: Structs, tuples and instances

[Bob I. <bo...@re...>]

On Oct 31, 2003, at 11:19 AM, Jack Jansen wrote:

>
> On 31 Oct 2003, at 15:14, Michael Hudson wrote:
>
>> Ronald Oussoren <ous...@ci...> writes:
>>
>>> On 31 okt 2003, at 11:54, Jack Jansen wrote:
>>>
>>>> Hmm, even if it isn't available from Python the objc core could make
>>>> it available. Using structmember for the various toolbox structures
>>>> is something that's also on my to-do list, but I haven't done
>>>> anything about it yet so I don't know how feasible this approach is.
>>>
>>> Do you mean the new PyStructSequence_Type as used by os.stat and
>>> time.localtime?
>>
>> Ah, that would be more likely than what he actually said :-)
>
> Right:-)
>
>>> Those "structures" are (sadly) read-only. I'm thinking of ...
>>
>> If you do do something about this, it might be worth offering a patch
>> to Python itself; tcgetattr at least could use such functionality.
>
> I'd love that... As I said I could put it to good use for the various 
> Mac toolbox objects.

While you're thinking about Mac toolbox objects, how about making 
FSSpec / FSRef / FSAlias easier to use?  Personally, I think it would 
be killer if I could str(fsSpec) and get the utf8 path out of it (or 
unicode(fsSpec) and get the unicode path out of it).

Thinking aloud here, I'm really liking the signatures.  It allows me to 
fix PyObjC methods without recompiling (if I want to), and they're 
pretty easy to understand (after looking at a lot of them).  I wish 
bgen wrapped modules had this kind of capability (but then we'd almost 
have ctypes).

-bob