pyobjc-dev — CVS commit notices go here

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

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

On Sunday, Dec 15, 2002, at 02:18 US/Eastern, David Eppstein wrote:
> I have a Python subclass of NSDocument, that wants to access the 
> NSDocument's window outlet.  Is it possible?  If I do window = 
> objc.IBOutlet("window"), I get None as the value of the outlet 
> (despite it being connected in the nib, and other outlets working).  
> But if I don't set the outlet in the Python code, I get exception: No 
> attribute window.  I can't see an accessor function that would give me 
> the same information in the NSDocument documentation.

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.

In the case of NSDocument, the iVar is named _window.   Because of the 
way documents manage their windows-- typically through instances of 
NSWindowController, but not always-- the -window method has a bunch of 
additional intelligence to deal with complex situations.

b.bum

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

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

I have a Python subclass of NSDocument, that wants to access the 
NSDocument's window outlet.  Is it possible?  If I do window = 
objc.IBOutlet("window"), I get None as the value of the outlet (despite it 
being connected in the nib, and other outlets working).  But if I don't set 
the outlet in the Python code, I get exception: No attribute window.  I 
can't see an accessor function that would give me the same information in 
the NSDocument documentation.

Obvious workaround: make a redundant outlet with another name...so this 
isn't urgent, but I would eventually like to know.
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] newbie question: How do I use my fink python installation?

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

On Saturday, Dec 14, 2002, at 02:54 US/Eastern, William Scott wrote:
> Is there any simple way to get this to play nice with /sw/bin/python 
> and all its modules?

Either hardwire the path in the bin-python-main.m to /sw/bin/python or 
set the default PythonBinPath to point to /sw/bin/python

(for you, that could be 'defaults write -globalDomain PythonBinPath 
/sw/bin/python' to set it across your machine.)

> Many thanks, and I apologize in advance for what may be a series of 
> really stupid basic questions.

Not stupid -- there isn't any documentation!

--

Larger question:  is there any reason why the various modules you have 
built via Fink cannot be built against the Apple supplied Python 2.2?  
What is the list of modules?   For distribution purposes-- i.e. if you 
wanted to create a standalone app that'll work on any 10.2.x machine, 
it would be better to build against the system provided python 2.2.

b.bum

[Pyobjc-dev] newbie question: How do I use my fink python installation?

[William S. <wg...@hy...>]

Hi:

First thanks very much for making pyobjc.   It looks to have great 
potential, especially for people like me wherein python represents the 
last best hope of ever writing any useful code.

I am an absolute beginner with this.

I fired up project builder and quicky realized that the python that 
imports objc must not be the same as my fink python installation, that 
has all the useful stuff I need like numeric, scientificpython, etc.   
At least it can't find these.

Is there any simple way to get this to play nice with /sw/bin/python 
and all its modules?

Many thanks, and I apologize in advance for what may be a series of 
really stupid basic questions.

Bill Scott



William G. Scott

Associate Professor
Department of Chemistry and Biochemistry
and The Center for the Molecular Biology of RNA
Sinsheimer Laboratories
University of California at Santa Cruz
Santa Cruz, California 95064
USA

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

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

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/

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

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

On Thursday, Dec 12, 2002, at 06:00 Europe/Amsterdam, David Eppstein 
wrote:

> On 12/11/02 1:20 PM -0800 David Eppstein <epp...@ic...> wrote:
>> It turns out that the "Before DECREF in normal" / "Release with dead
>> python" messages are caused by the outlets on File's Owner.  If I 
>> don't
>> set those outlets, the messages stop happening and my bus errors go 
>> away.
>> Is this a bug in pyobjc or in my understanding of how to use it?  I 
>> can
>> easily work around this by moving all the functionality from 
>> MyDocument
>> to another object created within the nib, but it would be helpful to
>> understand whether outlets to File's Owners are ok.
>
> I spoke too early.  This seems to be difficult to work around.
>
> The NSDocument class has an outlet, "window".  If I fail to connect 
> this outlet from the nib's "File's Owner" object to the nib's window, 
> new document windows come up unselected, and you have to click on them 
> to activate them (obviously undesired behavior).  But if I connect 
> this outlet, then closing a document window causes the log messages 
> and bus error death.  For that matter, to implement file i/o, I am 
> going to need outlets connecting the document object to the objects 
> where the data lives...
>
> I decided this was a serious enough bug for me to immediately go ahead 
> with Bill Bum's suggestion that I try the cvs version instead of the 
> 0.7 package.  Unfortunately, while the log messages are gone, the bus 
> error is still there...
>
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?

Ronald

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

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

On Wednesday, Dec 11, 2002, at 22:20 Europe/Amsterdam, David Eppstein 
wrote:
> Anyway, I want to say thank you, because writing this all out has 
> helped me track down one of the two bugs that were the subject of my 
> previous message.  It turns out that the "Before DECREF in normal" / 
> "Release with dead python" messages are caused by the outlets on 
> File's Owner.
The messages are leftovers from some debug code. The 
soon-to-be-released 0.8 version no longer prints these messages.

> If I don't set those outlets, the messages stop happening and my bus 
> errors go away.  Is this a bug in pyobjc or in my understanding of how 
> to use it?
It is probably a bug in pyobjc. Could you run your code with the CVS 
version of pyobjc, the bug is probably fixed by now.

Ronald

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

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

On 12/11/02 1:20 PM -0800 David Eppstein <epp...@ic...> wrote:
> It turns out that the "Before DECREF in normal" / "Release with dead
> python" messages are caused by the outlets on File's Owner.  If I don't
> set those outlets, the messages stop happening and my bus errors go away.
> Is this a bug in pyobjc or in my understanding of how to use it?  I can
> easily work around this by moving all the functionality from MyDocument
> to another object created within the nib, but it would be helpful to
> understand whether outlets to File's Owners are ok.

I spoke too early.  This seems to be difficult to work around.

The NSDocument class has an outlet, "window".  If I fail to connect this 
outlet from the nib's "File's Owner" object to the nib's window, new 
document windows come up unselected, and you have to click on them to 
activate them (obviously undesired behavior).  But if I connect this 
outlet, then closing a document window causes the log messages and bus 
error death.  For that matter, to implement file i/o, I am going to need 
outlets connecting the document object to the objects where the data 
lives...

I decided this was a serious enough bug for me to immediately go ahead with 
Bill Bum's suggestion that I try the cvs version instead of the 0.7 
package.  Unfortunately, while the log messages are gone, the bus error is 
still there...

Do you guys need a more formal bug report?  Should I try to work up a 
simpler test case or has my description been clear enough for you to 
reproduce it?

--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

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

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

On 12/11/02 3:13 PM -0500 bb...@ma... wrote:
> I haven't looked at the other specific problems, but will soon....
> however, you should really use the version in CVS.   We are on the verge
> of shipping 0.8 and it is leaps and bounds better than 0.7.

Ok, I guess.  I was holding off because I had the impression the 0.8 
release was imminent and it seemed like a better idea to wait until a 
relatively stable release than to try to hit a moving and sometimes buggy 
target.  When is the 0.8 release expected?

> We are going to cut 0.8 before doing a Cocoa-Python Multiple Document
> template, but that template will be one of the first things I do once 0.8
> ships.

I'd be happy to share my code but I'm not sure how useful you'd find it.
What I remember doing to make a document-based app was:
- Create class MyDocument (NSDocument) with methods modeled on the ObjC 
template
  (all I'm currently implementing are init and windowNibName, more to come 
later).
- Move the window and associated objects from MainMenu.nib to MyDocument.nib
  (the same nib whose name was returned from MyDocument.windowNibName)
- Set the "File's Owner" class in MyDocument.nib to MyDocument
  so I could set some outlets on it.
- Create a document type in the target having MyDocument as its document 
class


Anyway, I want to say thank you, because writing this all out has helped me 
track down one of the two bugs that were the subject of my previous 
message.  It turns out that the "Before DECREF in normal" / "Release with 
dead python" messages are caused by the outlets on File's Owner.  If I 
don't set those outlets, the messages stop happening and my bus errors go 
away.  Is this a bug in pyobjc or in my understanding of how to use it?  I 
can easily work around this by moving all the functionality from MyDocument 
to another object created within the nib, but it would be helpful to 
understand whether outlets to File's Owners are ok.

--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

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

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

I haven't looked at the other specific problems, but will soon.... 
however, you should really use the version in CVS.   We are on the 
verge of shipping 0.8 and it is leaps and bounds better than 0.7.

See the ChangeLog for an idea of how many things changed.   In 
particular, the examples have been considerably refined.

We are going to cut 0.8 before doing a Cocoa-Python Multiple Document 
template, but that template will be one of the first things I do once 
0.8 ships.   There are, as you have noted, some issues that we need to 
work through -- some may be fixed in 0.8.

b.bum

On Wednesday, December 11, 2002, at 01:17 PM, David Eppstein wrote:
> In order to try to learn how to program in Cocoa and pyobjc, I am 
> attempting to build a simple document-based application, using the 0.7 
> pyobjc package.  Mostly everything's working well, but I am having 
> trouble tracking down two bugs:

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

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

In order to try to learn how to program in Cocoa and pyobjc, I am 
attempting to build a simple document-based application, using the 0.7 
pyobjc package.  Mostly everything's working well, but I am having trouble 
tracking down two bugs:

(1) The usual Cocoa objective-C document-based template, when it starts up, 
creates a new document window.  It also does the same when selected in the 
dock and it doesn't already have a window.  My app does the dock-selection 
new window thing (without any code on my part, simply by adding a doc type 
to the target) but does not create a new window on startup.

(2) If I open and then close a document window, I get a string of scary 
looking log messages like:
    Before DECREF in normal
    Release with dead python
repeated several times.  If it were just a matter of some log messages, 
that would be ok, but then sometimes my program craps out with a bus error.

Do either of these look familiar to anyone?  I'm guessing the second one 
has to do with my lack of understanding of when I need to do explicit 
retain/release and when pyobjc will do it for me, but the new doc window 
creation process is all done by the nib, it doesn't involve any of my 
python code creating new objc objects...
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] bugs found while getting started

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

Brian,

Thanks for your feedback.

On Saturday, Dec 7, 2002, at 07:46 Europe/Amsterdam, Brian Slesinsky 
wrote:
>
> - modules.m doesn't compile on a UFS filesystem because the #include
> for NSAutoreleasePool.h has the wrong case.
>
> - HelloWorld.pm doesn't work unless I add "import AppKit" at the top.
We obviously don't use HelloWorld.py ourselves. Using "import AppKit",
or even better 'from AppKit import *; from Foundation import *' instead
of the calls to lookUpClass, is the right way to load the AppKit 
framework.
This used to work until several weeks ago due to a bug in the setup.py
script.

>
> - INSTALL claims that you need python 2.3, but setup.py checks for 
> python
> 2.2, and it seems to work so far.
Python 2.2 works just fine, INSTALL should be updated.

>
> I haven't tried anything else yet - what are good examples to try?
That depends on what you want to do with PyObjC

- TableModel is a simple GUI with a NIB file
- TableModel2 is the same program, but now as a Project Builder project
- WebServicesTool and Todo are more complicated GUI projects

The various python files in the Examples directory show some features
of PyObjC and are mostly code snippets that were used for testing the
module.

The documentation is far from complete, but the following rules for
translating from Objective-C should take you a long way:
- Instead of '#import <AppKit/AppKit.h>' do 'from AppKit import *'
- Likewise for Foundation.h
- Paste all elements of a method together and replace colons by
   underscores to get the Python method name (e.g. insertObject:atIndex:
   is insertObject_atIndex_ in Python).
- Python dicts can be used where NS(Mutable)Dictionaries are expected
- Python lists can be used where NS(Mutable)Arrays are expected

Ronald

[Pyobjc-dev] bugs found while getting started

[Brian S. <bsl...@be...>]

- modules.m doesn't compile on a UFS filesystem because the #include
for NSAutoreleasePool.h has the wrong case.

- HelloWorld.pm doesn't work unless I add "import AppKit" at the top.

- INSTALL claims that you need python 2.3, but setup.py checks for python
2.2, and it seems to work so far.

I haven't tried anything else yet - what are good examples to try?

----------------------------------------------------------------------
Brian Slesinsky

[Pyobjc-dev] Re: Using PyObjC to build production apps

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

On 12/4/02 10:42 AM -0500 Bill Bumgarner <bb...@co...> wrote:
> As Jack mentioned, there are a couple of rough edges, but PyObjC is
> definitely a viable means of building standalone GUI applications
> targeted to MacOSX in Python.
>
> If you do decide to delve deeper into PyObjC, please grab the
> source/examples/etc from pyobjc.sourceforge.net.   The current repository
> contents is way better than the last released version-- many bug fixes,
> many enhancements to make the programming experience considerably easier
> and more powerful.   Ronald Oussoren has made the interaction between
> ObjC and Python significantly more seamless and bullet proof than the
> last release;   he has gone so far as to identify and workaround some
> very subtle/nasty bugs in certain AppKit classes.

I just grabbed pyobjc itself and was pleasantly surprised -- the project 
builder's basic cocoa-python project works out of the box and creates very 
acceptably small standalone binary (at least I'm assuming it's standalone, 
haven't had a chance to try a different machine without pyobjc installed). 
I guess the rough edges must be further along because I didn't hit any yet. 
I intend to try some simple examples before I start working on the larger 
project I posted about before, but (to answer my previous question of when 
there will be a usable python for standalone apps) at first glance this 
looks usable now.  The ability to use Cocoa, Project Builder, and Interface 
Builder directly is probably a fair trade for lack of cross-platform 
portability.

I'm assuming something more would need to be done to get pyobjc 
applications running on pre-X.2 systems (like, tell users how to install 
python) but that is only a short-term problem.

Quick question on one of those simpler examples I want to try: I'm using a 
python script (based on JvR's W UI system) to make web pages from my 
digital camera's photos, and the user interface part is simple enough (a 
sequence of dialogs with separate windows displaying the photos) that it 
seems like a good place to start.  But has someone already worked on 
getting Python Imaging Library interoperating with pyobjc and X.2 
/usr/bin/python ?  I'm not familiar with compiling external modules for 
Python, but it looks like that part just involves putting PIL's .py and .so 
files in an appropriate place within the project, the part I'm more worried 
about is getting PIL images displayed in the Cocoa UI.

> The examples contained in the repository provide an excellent starting
> point.   In particular, the Web Services Tool and TableModel2  provide
> complete examples of building PyObjC applications using Project Builder
> as the IDE.  There are also examples that demonstrate building
> applications without using PB.

I get not founds when I click on them from pyobjc home -> Examples -> links 
in sidebar.  PyObjC definitely looks good for my purposes, so more 
documentation and examples would be very useful.

I eventually found non-broken links to the examples by browsing cvs, so I 
guess I can download them that way.

--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] PythonBrowser example/study + bug report

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

On Wednesday, Dec 4, 2002, at 22:57 Europe/Amsterdam, Just van Rossum 
wrote:

> Ronald Oussoren wrote:
>
>>> It can't include a proper traceback? (Sorry if this is naive, I
>>> know nothing about exceptions in ObjC yet.)
>>
>> That's another possibility, is there a function to translate a
>> traceback to a string (PyErr_Print writes to a file)?
>
> Hm, I can't find anything in C. If you can call back to Python, you 
> can use the
> traceback module. If you want I can try to write a C function that 
> calls
> traceback.py.

Calling back to Python would be no problem, I already use a callback to 
python for adding __getitem__ et. al. to classes. Converting exceptions 
is also not performance critical.

>
>>> On the other hand: wouldn't subclassing the module class also be an
>>> opportunity to speedup loading of Foundation and AppKit by doing
>>> things lazily? Oh, I don't think we need to subclass module at all:
>>> we can just inject an arbitrary object into sys.modules; I just
>>> tried it, and even "from FakeModule import *" works just fine.
>>
>> But wouldn't 'from AppKit import *' stop working if the AppKit 
>> 'module'
>> creates the proxies lazily?
>
> Not if the object has an __all__ attribute (I played around with this 
> the other
> day: for star-imports to work the object must either have an __all__ 
> attribute
> or a __dict__ atribute. I'm pretty sure __all__ is checked first.

Interesting.

>

>>
>> My local tree is already somewhat faster by somewhat optimizing
>> existing code and moving the actual loading code to Objective-C.
>
> "Somewhat" isn't quite enough I think... It would be nice if small 
> apps could
> start up quickly.
I know, that's why I didn't check in my changes just yet. We must get 
significantly faster if PyObjC is to be used in command-line utilities 
(the performance of Examples/addressbook.py is way too slow to be 
really usable)

>
> I think it's worthwhile to play with a fake module object implementing 
> a
> __getattr__ hook. How much of this proxy-building code is written in 
> Python, if
> any? If it's in (Obj)C, can you point me to the code so I can try to 
> understand
> it?

The proxy building code is all in Objective-C (and mostly this is just 
plain C code). ObjCClass_New in Modules/objc/objc-class.m builds proxy 
classes. This function is used by ObjC_GetClassList in 
Modules/objc/class-list.m when building the list of all classes known 
to the implementation.

Ronald

Re: [Pyobjc-dev] PythonBrowser example/study + bug report

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

Ronald Oussoren wrote:

> > It can't include a proper traceback? (Sorry if this is naive, I
> > know nothing about exceptions in ObjC yet.)
> 
> That's another possibility, is there a function to translate a 
> traceback to a string (PyErr_Print writes to a file)?

Hm, I can't find anything in C. If you can call back to Python, you can use the
traceback module. If you want I can try to write a C function that calls
traceback.py.

> > On the other hand: wouldn't subclassing the module class also be an
> > opportunity to speedup loading of Foundation and AppKit by doing
> > things lazily? Oh, I don't think we need to subclass module at all:
> > we can just inject an arbitrary object into sys.modules; I just
> > tried it, and even "from FakeModule import *" works just fine.
> 
> But wouldn't 'from AppKit import *' stop working if the AppKit 'module' 
> creates the proxies lazily?

Not if the object has an __all__ attribute (I played around with this the other
day: for star-imports to work the object must either have an __all__ attribute
or a __dict__ atribute. I'm pretty sure __all__ is checked first.

> I've done some experiments to find why 
> importing AppKit is as slow as it is. Actually loading the framework 
> isn't that expensive, the problem is really in creating all proxy 
> classes and specifically in walking the method-tables of Objective-C 
> classes. I'll check if I can somehow postpone this until it is really 
> needed (someone doing dir(NSObject) or creating an instance of the 
> proxy [or one of its subclasses]).
>
> My local tree is already somewhat faster by somewhat optimizing 
> existing code and moving the actual loading code to Objective-C.

"Somewhat" isn't quite enough I think... It would be nice if small apps could
start up quickly.

I think it's worthwhile to play with a fake module object implementing a
__getattr__ hook. How much of this proxy-building code is written in Python, if
any? If it's in (Obj)C, can you point me to the code so I can try to understand
it?

Just

Re: [Pyobjc-dev] PythonBrowser example/study + bug report

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

On Sunday, Dec 1, 2002, at 21:55 Europe/Amsterdam, Just van Rossum 
wrote:

>> 2) The exception raised when converting from Python to Objective-C
>> exceptions should always include the file+line where the exception
>> was raised.
>
> It can't include a proper traceback? (Sorry if this is naive, I know 
> nothing
> about exceptions in ObjC yet.)

That's another possibility, is there a function to translate a 
traceback to a string (PyErr_Print writes to a file)?


>
>> BTW. 'objc.setVerbose' should IMHO be a property ('objc.verbose = 1'
>> instead of 'objc.setVerbose(1)'), but I'm pretty sure that it is
>> impossible to add properties to a module without subclassing
>> types.ModuleType. This is too bad because module-properties would be a
>> neat way to proxy global variables in Objective-C frameworks.
>
> What about an object in the module with a special name, handling the 
> access to
> globals?
>
> On the other hand: wouldn't subclassing the module class also be an 
> opportunity
> to speedup loading of Foundation and AppKit by doing things lazily? 
> Oh, I don't
> think we need to subclass module at all: we can just inject an 
> arbitrary object
> into sys.modules; I just tried it, and even "from FakeModule import *" 
> works
> just fine.

But wouldn't 'from AppKit import *' stop working if the AppKit 'module' 
creates the proxies lazily? I've done some experiments to find why 
importing AppKit is as slow as it is. Actually loading the framework 
isn't that expensive, the problem is really in creating all proxy 
classes and specifically in walking the method-tables of Objective-C 
classes. I'll check if I can somehow postpone this until it is really 
needed (someone doing dir(NSObject) or creating an instance of the 
proxy [or one of its subclasses]).

My local tree is already somewhat faster by somewhat optimizing 
existing code and moving the actual loading code to Objective-C.

Ronald

[Pyobjc-dev] using services from Python with NSPerformService

[Mathieu L. <ze...@ne...>]

import objc
from AppKit import *

NSPasteboard = objc.lookUpClass('NSPasteboard')
paste = NSPasteboard.pasteboardWithName_("carotte")
carotteBoardType = [ NSStringPboardType]
paste.declareTypes_owner_(carotteBoardType,objc.nil)
a = paste.setString_forType_("Hello World!",NSStringPboardType)
print "the pastboard work :", a
b = NSPerformService("Make New Sticky Note.",paste)
print "the service work :",b

----------------------------------
but it doesn't work, and i don't know where can i find the mistake, 
there's no error information nor logs. Is there any method for 
debugging pyobjc code?

M.

[Pyobjc-dev] Using PyObjC to build production apps

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

On Wednesday, December 4, 2002, at 04:15 AM, 
pyt...@py... wrote:
> If you are developing a turnkey application I think I would suggest 
> PyObjC. It can build on the installed /usr/bin/python, and an 
> application in PyObjC will fit all your requirements (possibly with 
> the exception of the 2MB download, I'm not 100% sure of that). 
> Building a fullblown application with PyObjC still has a few rough 
> edges, but they're being ironed out quickly.

As Jack mentioned, there are a couple of rough edges, but PyObjC is 
definitely a viable means of building standalone GUI applications 
targeted to MacOSX in Python.

If you do decide to delve deeper into PyObjC, please grab the 
source/examples/etc from pyobjc.sourceforge.net.   The current 
repository contents is way better than the last released version-- many 
bug fixes, many enhancements to make the programming experience 
considerably easier and more powerful.   Ronald Oussoren has made the 
interaction between ObjC and Python significantly more seamless and 
bullet proof than the last release;   he has gone so far as to identify 
and workaround some very subtle/nasty bugs in certain AppKit classes.

The examples contained in the repository provide an excellent starting 
point.   In particular, the Web Services Tool and TableModel2  provide 
complete examples of building PyObjC applications using Project Builder 
as the IDE.  There are also examples that demonstrate building 
applications without using PB.

Just van Rossum has done an incredible job of providing tools to the 
PyObjC project.

In particular, Just contributed a mechanism via which classes defined 
in interface files [NIB files] are automatically created when the NIB 
file is loaded.   That is, the entire step of keeping your source files 
in sync with your interface files has been eliminated-- "it just 
works".   In this context, it is less work to build a PyObjC based 
Cocoa app than a Java or ObjC based Cocoa app!

Personally, I'm using PyObjC to build two production quality 
applications, one of which is relatively complex [it is really a suite 
of applications that share two frameworks -- one framework of which is 
almost entirely implemented in Python with a PyObjC bridged layer that 
the rest of the app uses].   I chose this route not because I like 
living on the bleeding edge, but because using PyObjC cut a huge amount 
of gnarly, bug prone, code out of my project and the end result is a 
more robust applications that performs every bit as well as a 
pure-C/ObjC counterpart.   (Specifically, I replaced the entire web 
services layer of my application with a python implementation of the 
web services client.   As an added advantage, my python based web 
services client now works seamlessly across all operating systems / 
platforms, yet my OS X GUI client remains a pure Cocoa/OS X UI 
experience.)

Very cool stuff -- we have come a long, long way since PyObjC '96!

b.bum

Re: [Pyobjc-dev] NSRect?

[Ronald_Oussoren <ous...@ci...>]

On Sun, 1 Dec 2002 23:46:06 -0700, Jiva DeVoe wrote
> So where's NSRect fall in the scheme of pyobjc?

NSRect, and struct-types in general, are converted to/from Python tuples. For
NSRect this tuple is of the form ((origin_x, origin_y), (size_x, size_y)).

The translation is fully automatic based on the signature of the struct (the
string "returned" by @encode(NSRect)).

Ronald

[Pyobjc-dev] NSRect?

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

So where's NSRect fall in the scheme of pyobjc?

Re: [Pyobjc-dev] PythonBrowser example/study + bug report

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

Ronald Oussoren wrote:

> I'll look into this.

Also the fact that reporting the error actually causes a real crash somehow? In
case you missed it:

2002-11-30 15:31:24.633 Console[20835] Exception raised during posting of
notification.  Ignored.  exception: *** NSRunStorage, _NSBlockNumberForIndex():
index (36561) beyond array bounds (36561)

I've found another crashing bug: In PythonBrowser.py, if PythonItem doesn't
subclass NSObject but object it crashes right away. If I subclass from nothing
(a classic class) it crashes later (eg. after clicking). Are crashes expected if
Python objects are fed to the ObjC runtime?

[error reporting]
> What I'm currently thinking of:
> 
> 1) objc.setVerbose(newValue) -> None newValue is a boolean. If
> newValue is true the PyObjC runtime is more verbose, this includes
> calling PyErr_Print when translating from Python to Objective-C
> exceptions.

Sounds good.

> 2) The exception raised when converting from Python to Objective-C
> exceptions should always include the file+line where the exception
> was raised.

It can't include a proper traceback? (Sorry if this is naive, I know nothing
about exceptions in ObjC yet.)

> BTW. 'objc.setVerbose' should IMHO be a property ('objc.verbose = 1' 
> instead of 'objc.setVerbose(1)'), but I'm pretty sure that it is 
> impossible to add properties to a module without subclassing 
> types.ModuleType. This is too bad because module-properties would be a 
> neat way to proxy global variables in Objective-C frameworks.

What about an object in the module with a special name, handling the access to
globals?

On the other hand: wouldn't subclassing the module class also be an opportunity
to speedup loading of Foundation and AppKit by doing things lazily? Oh, I don't
think we need to subclass module at all: we can just inject an arbitrary object
into sys.modules; I just tried it, and even "from FakeModule import *" works
just fine.

Just

Re: [Pyobjc-dev] How to implement a protocol?

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

See the Web Services Tool example in the cvs repository -- it 
implements a toolbar...

On Sunday, December 1, 2002, at 01:21 PM, Jiva DeVoe wrote:

> I am trying to set up a toolbar for my app.  So I am implementing the 
> delegate methods for that.  One of the delegate methods I need to 
> implement is this:
>
> - (NSToolbarItem *)toolbar:(NSToolbar *)toolbar 
> itemForItemIdentifier:(NSString *)itemIdentifier 
> willBeInsertedIntoToolbar:(BOOL)flag;
>
> How do I write this as a python method to implement this?  Right now, 
> it's complaining that I haven't implemented all the methods for this.  
> I suspect this is the one it doesn't like.

Re: [Pyobjc-dev] How to implement a protocol?

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

Subclass your delegate from a 'normal' objective-C class (like 
NSObject) and AppKit.NSToolbarDelegate to pick up the right method 
signatures. The declaration for the method you mention below is:

	def toolbaar_itemForItemIdentifier_willBeInsertedIntoToolbar_(self, 
toolbar, itemIdentifier, flag):
		pass

You'll also have to define 'toolbarDefaultItemIdentifiers:' and 
'toolbarAllowedItemIdentifiers:'.

Ronald

On Sunday, Dec 1, 2002, at 19:21 Europe/Amsterdam, Jiva DeVoe wrote:

> I am trying to set up a toolbar for my app.  So I am implementing the 
> delegate methods for that.  One of the delegate methods I need to 
> implement is this:
>
> - (NSToolbarItem *)toolbar:(NSToolbar *)toolbar 
> itemForItemIdentifier:(NSString *)itemIdentifier 
> willBeInsertedIntoToolbar:(BOOL)flag;
>
> How do I write this as a python method to implement this?  Right now, 
> it's complaining that I haven't implemented all the methods for this.  
> I suspect this is the one it doesn't like.
>
>
>
> -------------------------------------------------------
> 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
>

[Pyobjc-dev] How to implement a protocol?

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

I am trying to set up a toolbar for my app.  So I am implementing the 
delegate methods for that.  One of the delegate methods I need to 
implement is this:

- (NSToolbarItem *)toolbar:(NSToolbar *)toolbar 
itemForItemIdentifier:(NSString *)itemIdentifier 
willBeInsertedIntoToolbar:(BOOL)flag;

How do I write this as a python method to implement this?  Right now, 
it's complaining that I haven't implemented all the methods for this.  
I suspect this is the one it doesn't like.