pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] 1.0 released

[Richard C. <sun...@ma...>]

Hello,

On Wednesday, October 8, 2003, at 06:45  pm, Ronald Oussoren wrote:

> PyObjC 1.0 is (finally ;-) released!

Cool!

> I've tagged the CVS tree: 'release_1_0' is the release, 'branch_1_0' 
> is a branch for creating a 1.0.x release (should that be necessary). 
> The files have been uploaded to SF and should be available "soon".
>
> MacPython 2.3 users can get instant gratification by pointing PackMan 
> to 
> http://pyobjc.sf.net/packman/pyobjc-stable-6.6-Power_Macintosh.plist 
> (and ...-7.0-... for those of you who run MacPython 2.3 on Panther).

Unfortunately that doesn't seem to work for me (10.2.8 / MacPython 2.3) 
I get a Requires unknown AppleDevTools error message - I do have the 
apple dev tools installed.

> I'll send the announcement below to other lists some time tomorrow, I 
> want to be reasonably sure that the SF mirrors have picked up the 
> archives/installers before telling the world about them.

There is a typo in you're url on the homepage, the available link 
points to sourceforget instead of sourceforge.

Cheers,

Richard

[Pyobjc-dev] ANN: ZopeEditManager 0.7 Released

[Zachery B. <zb...@ur...>]

Hey, all. Wanted to just announce my first PyObjC application, 
ZopeEditManager.

I really appreciated all the help that went into this, in particular 
Bill Bumgarner during the early phases when I bent his ear off-list far 
too often :)

   <http://www.zope.org/Members/urbanape/ZopeEditManager/>

Thanks so much for all your help!

Zac

[Pyobjc-dev] 1.0 released

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

PyObjC 1.0 is (finally ;-) released!

I've tagged the CVS tree: 'release_1_0' is the release, 'branch_1_0' is 
a branch for creating a 1.0.x release (should that be necessary). The 
files have been uploaded to SF and should be available "soon".

MacPython 2.3 users can get instant gratification by pointing PackMan 
to http://pyobjc.sf.net/packman/pyobjc-stable-6.6-Power_Macintosh.plist 
(and ...-7.0-... for those of you who run MacPython 2.3 on Panther).

I'll send the announcement below to other lists some time tomorrow, I 
want to be reasonably sure that the SF mirrors have picked up the 
archives/installers before telling the world about them.

Ronald


ANN: PyObjC 1.0

The PyObjC developers are happy to announce the 1.0 release of PyObjC. 
It
is available for download at http://pyobjc.sourceforge.net/.

PyObjC is a bridge between Python and Objective-C.  It allows full
featured Cocoa applications and plugins to be written in pure Python.  
It
is also easy to use other frameworks containing Objective-C class 
libraries
from Python and to mix in Objective-C, C and C++ source.

Python is a highly dynamic programming language with a shallow learning
curve.  It combines remarkable power with very clear syntax.

The installer package includes a number of Project Builder templates for
easily creating new Cocoa-Python projects, as well as support for
syntax-coloring Python files in Project Builder.

PyObjC also supports full introspection of Objective-C classes and
direct invocation of Objective-C APIs from the interactive interpreter.

PyObjC requires MacOS X 10.2 or later.  PyObjC works both with the Apple
provided Python installation in MacOS X 10.2 (and later) and with
MacPython 2.3.  Users of MacPython 2.3 can install PyObjC though the
PackageManager application.

Version 1.0 fixes a number of bugs in the beta release, and fixes some
inconsitencies in the exposed interfaces. It also includes improved 
support
for Key-Value Coding (the NSKeyValue coding informal protocol).

PyObjC is released with an open source license.

Re: [Pyobjc-dev] info.plist not being regarded?

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

On Tuesday, Oct 7, 2003, at 20:48 America/New_York, Zachery Bir wrote:

> On Oct 7, 2003, at 6:05 PM, Jack Jansen wrote:
>
>> Wild guess: you're not overriding the values in the plist file through
>> a localized English.lproj/InfoPlist.strings file, are you?
>
> GAH! Yes. But it didn't show up in greps because it's all like this:
>
> ^@C^@F^@B^@u...
>
> Thanks. Can I just get rid of it, or overwrite it with plain ASCII 
> representations?

Toss it, won't hurt.

-bob

Re: [Pyobjc-dev] info.plist not being regarded?

[Zachery B. <zb...@ur...>]

On Oct 7, 2003, at 6:05 PM, Jack Jansen wrote:

> Wild guess: you're not overriding the values in the plist file through
> a localized English.lproj/InfoPlist.strings file, are you?

GAH! Yes. But it didn't show up in greps because it's all like this:

^@C^@F^@B^@u...

Thanks. Can I just get rid of it, or overwrite it with plain ASCII 
representations?

Zac

Re: [Pyobjc-dev] info.plist not being regarded?

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

> (Never mind my last post: I went back to your original post, and it all
> looks just fine. I'm at a loss what's going on.)

Wild guess: you're not overriding the values in the plist file through
a localized English.lproj/InfoPlist.strings file, are you?
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

Re: [Pyobjc-dev] info.plist not being regarded?

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

(Never mind my last post: I went back to your original post, and it all
looks just fine. I'm at a loss what's going on.)

Just

Re: [Pyobjc-dev] info.plist not being regarded?

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

Zachery Bir wrote:

> > Have you tried logging out and back in?  LaunchServices and Finder
> > cache a lot of information, I wouldn't be terribly surprised that
> > it cached version numbers.  Another way to check would be to copy
> > the bundle to somewhere else from the terminal and check that from
> > Finder.
> 
> Yup, tried both. Same result in either case. It's prolly not all that
> bad, it's just the version number, and six-tenths of a version less
> should just as well convey its lack of polish :)

Are you 100% sure your buildapp.py is importing the same version of
bundlebuilder.py as the one you're looking at? PyObjC installs a version
if there isn't one, so it really should not have installed one, but you
may want to make sure. Another thing to check would be whether you made
a typo in your buildapp.py script. Eg. the buildapp.py for drawbot
contains this line:

    CFBundleShortVersionString = "0.9a1",

That version string is indeed visible in the Finder.

Just

Re: [Pyobjc-dev] info.plist not being regarded?

[Zachery B. <zb...@ur...>]

On Oct 7, 2003, at 4:51 PM, Bob Ippolito wrote:

> Have you tried logging out and back in?  LaunchServices and Finder 
> cache a lot of information, I wouldn't be terribly surprised that it 
> cached version numbers.  Another way to check would be to copy the 
> bundle to somewhere else from the terminal and check that from Finder.

Yup, tried both. Same result in either case. It's prolly not all that 
bad, it's just the version number, and six-tenths of a version less 
should just as well convey its lack of polish :)

Zac

Re: [Pyobjc-dev] info.plist not being regarded?

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

On Tuesday, Oct 7, 2003, at 16:44 America/New_York, Zachery Bir wrote:

> On Oct 7, 2003, at 4:38 PM, Just van Rossum wrote:
>
>> Zachery Bir wrote:
>>
>>> So, I've got some plist assignments being made in my buildapp.py
>>> script, and I can verify that the values are placed properly in the
>>> Info.plist inside the Contents directory of my bundle, but Finder
>>> doesn't display the appropriate version info - it's always reported  
>>> as
>>> 0.1. Any ideas?
>>
>> Sounds similar to a bundlebuilder bug that was recently fixed. I don't
>> know off hand which PyObjC version contains the fixed version  
>> (probably
>> after 1.0b1), but you can grab the latest bundlebuilder.py here:
>>
>> http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/ 
>> src/
>> Lib/plat-mac/bundlebuilder.py?rev=1.36
>
> Downloaded that to my Documents directory, diffed against what's in my  
> current 2.3, and there are no differences...

Have you tried logging out and back in?  LaunchServices and Finder  
cache a lot of information, I wouldn't be terribly surprised that it  
cached version numbers.  Another way to check would be to copy the  
bundle to somewhere else from the terminal and check that from Finder.

-bob

Re: [Pyobjc-dev] info.plist not being regarded?

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

On Tuesday, Oct 7, 2003, at 16:38 America/New_York, Just van Rossum  
wrote:

> Zachery Bir wrote:
>
>> So, I've got some plist assignments being made in my buildapp.py
>> script, and I can verify that the values are placed properly in the
>> Info.plist inside the Contents directory of my bundle, but Finder
>> doesn't display the appropriate version info - it's always reported as
>> 0.1. Any ideas?
>
> Sounds similar to a bundlebuilder bug that was recently fixed. I don't
> know off hand which PyObjC version contains the fixed version (probably
> after 1.0b1), but you can grab the latest bundlebuilder.py here:
>
> http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/ 
> src/
> Lib/plat-mac/bundlebuilder.py?rev=1.36

Somewhat related, you can also get an updated version of PyObjC itself  
from my PackageManager repository:

http://undefined.org/python/pimp/ for instructions

I forgot to tell anyone I went ahead and compiled a CVS version (it was  
marked as 1.0rc3) this weekend and put it up there.  I also changed my  
version checker in the plist to use distutils.version.LooseVersion so  
it should compare correctly for those of you with an earlier version  
installed.

This doesn't include bundlebuilder and the examples though, just the  
PyObjC package.

-bob

Re: [Pyobjc-dev] info.plist not being regarded?

[Zachery B. <zb...@ur...>]

On Oct 7, 2003, at 4:38 PM, Just van Rossum wrote:

> Zachery Bir wrote:
>
>> So, I've got some plist assignments being made in my buildapp.py
>> script, and I can verify that the values are placed properly in the
>> Info.plist inside the Contents directory of my bundle, but Finder
>> doesn't display the appropriate version info - it's always reported as
>> 0.1. Any ideas?
>
> Sounds similar to a bundlebuilder bug that was recently fixed. I don't
> know off hand which PyObjC version contains the fixed version (probably
> after 1.0b1), but you can grab the latest bundlebuilder.py here:
>
> http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/ 
> src/
> Lib/plat-mac/bundlebuilder.py?rev=1.36

Downloaded that to my Documents directory, diffed against what's in my  
current 2.3, and there are no differences...

Zac

Re: [Pyobjc-dev] info.plist not being regarded?

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

Zachery Bir wrote:

> So, I've got some plist assignments being made in my buildapp.py 
> script, and I can verify that the values are placed properly in the 
> Info.plist inside the Contents directory of my bundle, but Finder 
> doesn't display the appropriate version info - it's always reported as 
> 0.1. Any ideas?

Sounds similar to a bundlebuilder bug that was recently fixed. I don't
know off hand which PyObjC version contains the fixed version (probably
after 1.0b1), but you can grab the latest bundlebuilder.py here:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/
Lib/plat-mac/bundlebuilder.py?rev=1.36

Just

[Pyobjc-dev] info.plist not being regarded?

[Zachery B. <zb...@ur...>]

So, I've got some plist assignments being made in my buildapp.py 
script, and I can verify that the values are placed properly in the 
Info.plist inside the Contents directory of my bundle, but Finder 
doesn't display the appropriate version info - it's always reported as 
0.1. Any ideas?

Thanks,

Zac

plist = Plist( CFBundleIdentifier = "com.urbanape.zopeeditmanager"
              , CFBundleShortVersionString = "0.7"
              , CFBundleGetInfoString = "0.7"
              , NSHumanReadableCopyright = "Copyright 2003 Zope 
Corporation"
              )

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CFBundleExecutable</key>
	<string>ZopeEditManager</string>
	<key>CFBundleGetInfoString</key>
	<string>0.7</string>
	<key>CFBundleIconFile</key>
	<string>ZEM.icns</string>
	<key>CFBundleIdentifier</key>
	<string>com.urbanape.zopeeditmanager</string>
	<key>CFBundleName</key>
	<string>ZopeEditManager</string>
	<key>CFBundlePackageType</key>
	<string>APPL</string>
	<key>CFBundleShortVersionString</key>
	<string>0.7</string>
	<key>CFBundleSignature</key>
	<string>????</string>
	<key>NSHumanReadableCopyright</key>
	<string>Copyright 2003 Zope Corporation</string>
	<key>NSMainNibFile</key>
	<string>MainMenu</string>
	<key>NSPrincipalClass</key>
	<string>NSApplication</string>
</dict>
</plist>

Re: [Pyobjc-dev] Re: Pyobjc-dev digest, Vol 1 #373 - 3 msgs

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

On Monday, Oct 6, 2003, at 13:09 America/New_York, Ronald Oussoren 
wrote:

> BTW. there's two reasons I'm working on a GNUstep port, the first is 
> the coolness factor and the second is improving the quality of the 
> MacOSX port by exposing the bridge to slightly different conditions.
>
> BTW2. my Linux box is headless, and I won't install X11 on it. This 
> means someone else will have to port the AppKit wrappers. That will be 
> pretty easy once the core code works.

I have a "headed" X11 box and a Win XP (which I'm pretty sure can run 
*some* of GNUStep if one is so inclined) laptop at work.. so let me 
know when it's ready for me to start poking at.

-bob

Re: [Pyobjc-dev] Re: Pyobjc-dev digest, Vol 1 #373 - 3 msgs

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

On 6 okt 2003, at 16:17, Gary Robinson wrote:

>>> I thought this was interesting. too bad GnuStep's PyObjC connection 
>>> is
>>> languishing or it might have provided a quicker path to x-platform.
>>
>> All it needs is a maintainer, feel free to volunteer ;)
>
> I wish we had the bandwidth to take it on!!!! But we're just flat-out
> against the wall trying to get done the stuff we absolutely must get 
> done
> ASAP.

I am, very slowly, working on a GNUstep port. The lack of usefull 
documentation on the GNU runtime isn't helpfull :-). I'll start 
checking in after the release of PyObjC 1.0.

The script below now works, but the unittests still cause many, many 
crashes.

import objc

class Foo (objc.runtime.NSObject):
         def init(self):
                 print "hello"
                 return self
         def description(self):
                 return "foo"

print Foo.alloc().init()

BTW. there's two reasons I'm working on a GNUstep port, the first is 
the coolness factor and the second is improving the quality of the 
MacOSX port by exposing the bridge to slightly different conditions.

BTW2. my Linux box is headless, and I won't install X11 on it. This 
means someone else will have to port the AppKit wrappers. That will be 
pretty easy once the core code works.

Ronald

Re: [Pyobjc-dev] Re: Pyobjc-dev digest, Vol 1 #373 - 3 msgs

[Gary R. <gro...@tr...>]

>> I thought this was interesting. too bad GnuStep's PyObjC connection is
>> languishing or it might have provided a quicker path to x-platform.
> 
> All it needs is a maintainer, feel free to volunteer ;)

I wish we had the bandwidth to take it on!!!! But we're just flat-out
against the wall trying to get done the stuff we absolutely must get done
ASAP. 

We're currently looking at PythonCard as an alternative strategy for our
software. Our UI needs are currently pretty simple, so we're thinking it may
fit the bill.

--Gary

-- 
Putting http://wecanstopspam.org in your email helps it pass through
overzealous spam filters.

Gary Robinson
CEO
Transpose, LLC
gro...@tr...
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454

Re: [Pyobjc-dev] Re: Pyobjc-dev digest, Vol 1 #373 - 3 msgs

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

On Monday, Oct 6, 2003, at 10:02 America/New_York, Gary Robinson wrote:

> I thought this was interesting. too bad GnuStep's PyObjC connection is
> languishing or it might have provided a quicker path to x-platform.

All it needs is a maintainer, feel free to volunteer ;)

-bob

[Pyobjc-dev] Re: Pyobjc-dev digest, Vol 1 #373 - 3 msgs

[Gary R. <gro...@tr...>]

I thought this was interesting. too bad GnuStep's PyObjC connection is
languishing or it might have provided a quicker path to x-platform.

--Gary


> 
> --__--__--
> 
> Message: 2
> Date: Sun, 5 Oct 2003 18:02:25 -0400
> From: Bob Ippolito <bo...@re...>
> To: pyo...@li...
> Subject: [Pyobjc-dev] GNUStep Renaissance - rocks in PyObjC!
> 
> GNUStep Renaissance ( http://www.gnustep.it/Renaissance/ ) is basically
> a very terse XML way of describing interfaces, as a cross-platform
> replacement for nib files.  It works perfectly in PyObjC (even outlets
> seem to work with AutoBaseClass and such).  Although I don't
> particularly care about cross-platform at this point, it's very useful
> for dynamically defining an interface.
> 
> Basically what I'm doing with a friend of mine is adding a drawer to
> DrawBot, where the drawer's contents are defined dynamically by the
> Python code.  What this drawer will be used for is taking the constants
> out of the code and assigning them to sliders, checkboxes, color wells,
> etc.  I spent a few hours looking around for how to create Cocoa
> interfaces by hand, and it seems entirely possible, but I couldn't find
> out how to do the automatic layout stuff.  Renaissance, which I found
> from a mailing list post on Google when poking around for nib-less
> Cocoa information, solves this problem elegantly and easily from
> PyObjC, especially because constructing XML from Python is cake.  I'm
> just starting the implementation, so I don't know if I'll have to
> modify Renaissance for my purposes (hopefully not), but I'm extremely
> pleased so far and I figured this was worth pointing out.
> 
> -bob
> 
> 
> 
>
> End of Pyobjc-dev Digest
> 

Re: [Pyobjc-dev] GNUStep Renaissance - rocks in PyObjC!

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

Bob Ippolito:

> [...] What this drawer will be used for is taking the constants out
> of the code and assigning them to sliders, checkboxes, color wells,
> etc.

Sort of what I did in GnuplotEddie, although the layout itself is
static, but it displays different variables and attributes, depen-
ding on what you select in the Python/Gnuplot code.

   http://python.net/~gherman/GnuplotEddie.html

Dinu

--
Dinu C. Gherman
......................................................................
"The empires of the future are the empires of the mind."
(Winston Churchill)

[Pyobjc-dev] GNUStep Renaissance - rocks in PyObjC!

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

GNUStep Renaissance ( http://www.gnustep.it/Renaissance/ ) is basically 
a very terse XML way of describing interfaces, as a cross-platform 
replacement for nib files.  It works perfectly in PyObjC (even outlets 
seem to work with AutoBaseClass and such).  Although I don't 
particularly care about cross-platform at this point, it's very useful 
for dynamically defining an interface.

Basically what I'm doing with a friend of mine is adding a drawer to 
DrawBot, where the drawer's contents are defined dynamically by the 
Python code.  What this drawer will be used for is taking the constants 
out of the code and assigning them to sliders, checkboxes, color wells, 
etc.  I spent a few hours looking around for how to create Cocoa 
interfaces by hand, and it seems entirely possible, but I couldn't find 
out how to do the automatic layout stuff.  Renaissance, which I found 
from a mailing list post on Google when poking around for nib-less 
Cocoa information, solves this problem elegantly and easily from 
PyObjC, especially because constructing XML from Python is cake.  I'm 
just starting the implementation, so I don't know if I'll have to 
modify Renaissance for my purposes (hopefully not), but I'm extremely 
pleased so far and I figured this was worth pointing out.

-bob

[Pyobjc-dev] [ pyobjc-Bugs-818304 ] objc.loadBundle doesn't take relative paths

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

Bugs item #818304, was opened at 2003-10-05 17:24
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=818304&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: objc.loadBundle doesn't take relative paths

Initial Comment:
It's not documented that the bundle_path kwarg MUST be an 

absolute path.  The implementation should be changed to 

use os.path.abspath, or the documentation should make a 

note of this.  I banged my head against the wall for a few 

minutes figuring this out :)

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

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

[Pyobjc-dev] Duelling code styles

[Kevin M. <kev...@ma...>]

I have an app I wrote in pure Python & PYObjC:

http://homepage.mac.com/kevinmarks/iIRC.dmg

I want to bring in some ObjC classes I wrote for another App, and I am 
stumped as to how. I tried creating a new PB Project of type 
Cocoa-Python-ObjC

But it is hard to work out what I am supposed to modify in this 
template.

How do I get the Classes in other files invoked by my Nib?

Do I add my class to the support framework instead of Hue?

How do I adapt my existing Python classes to fit in?

[Pyobjc-dev] [ pyobjc-Bugs-814683 ] crash in dataFromPropertyList_format_err

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

orDescription_
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"

Bugs item #814683, was opened at 2003-09-29 21:48
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=814683&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martina Oefelein (oefe)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash in dataFromPropertyList_format_err

orDescription_

Initial Comment:
NSPropertyListSerialization.dataFromPropertyList_format_err

crashes.



Observed with Jaguar Python and PyObjC 1.0rc1, 1.0rc3 as 

well as with MacPython 2.3 and PyObjC 1.0b1



Example:

Python 2.2 (#1, 11/12/02, 23:31:59) 

[GCC Apple cpp-precomp 6.14] on darwin

Type "help", "copyright", "credits" or "license" for more 

information.

>>> import objc

>>> objc.__version__

'1.0rc3'

>>> from Foundation import *

>>> plist = 0

>>> 

NSPropertyListSerialization.dataFromPropertyList_format_err

orDescription_(plist, NSPropertyListXMLFormat_v1_0)

(<NSCFData objective-c instance 0x5386f0>, None)

>>> 

NSPropertyListSerialization.dataFromPropertyList_format_err

orDescription_(plist, NSPropertyListXMLFormat_v1_0)

Bus error



Crash Log:

Date/Time:  2003-08-15 13:45:22 +0200

OS Version: 10.2.6 (Build 6L60)

Host:       Vercingetorix.local.



Command:    python

PID:        1313



Exception:  EXC_BAD_ACCESS (0x0001)

Codes:      KERN_PROTECTION_FAILURE (0x0002) at 

0x00000004



Thread 0 Crashed:

 #0   0x002679f8 in depythonify_unsigned_int_value 

(objc_support.m:770)

 #1   0x002775e0 in ObjC_FFICaller (libffi_support.m:1004)

 #2   0x0027176c in objcsel_call (selector.m:563)

 #3   0x00045930 in PyObject_Call

 #4   0x0005df64 in PyEval_GetFuncDesc

 #5   0x0005b32c in PyEval_EvalCode

 #6   0x0005c634 in PyEval_EvalCodeEx

 #7   0x00058a80 in PyEval_EvalCode

 #8   0x00027e90 in PyRun_FileExFlags

 #9   0x00026c70 in PyRun_InteractiveOneFlags

 #10  0x00026a58 in PyRun_InteractiveLoopFlags

 #11  0x000268f0 in PyRun_AnyFileExFlags

 #12  0x000069f0 in Py_Main

 #13  0x00002970 in start

 #14  0x000027f0 in start



PPC Thread State:

  srr0: 0x002679f8 srr1: 0x0000f030                vrsave: 

0x00000000

   xer: 0x00000000   lr: 0x002679dc  ctr: 0x00266a5c   mq: 

0x00000000

    r0: 0x0009d840   r1: 0xbffff0a0   r2: 0x002879dc   r3: 

0x00000000

    r4: 0x0027b628   r5: 0xbffff150   r6: 0x00000000   r7: 

0xffffffff

    r8: 0x002766c0   r9: 0x00000000  r10: 0x00000049  r11: 

0x00000026

   r12: 0x90009ee0  r13: 0x00000001  r14: 0x00000008  

r15: 0xbffff1c8

   r16: 0x00000049  r17: 0x00000000  r18: 0x00000000  

r19: 0x00280b78

   r20: 0x00281268  r21: 0x00000049  r22: 0xbffff1c0  r23: 

0x0000000c

   r24: 0x00121800  r25: 0x0027b628  r26: 0x00000003  

r27: 0x0000000c

   r28: 0x00000000  r29: 0x00000000  r30: 0x00514928  

r31: 0x002679dc



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

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

[Pyobjc-dev] ANN: DrawBot, an environment for programming 2D graphics

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

I'm happy to announce a first public version of "DrawBot", an
environment for 2D graphics programming.

DrawBot is a minimal "IDE", that allows you to write simple Python
scripts that generate two-dimensional graphics. The builtin graphics
primitives are currently pretty braindead, this version only supports
rectangles, ovals and (bezier) paths and polygons. A future version will
also support text and images.

DrawBot is written in Python. The binary download is fully
self-sufficient (ie. it doesn't need a Python install around), but if
you use or build it from the source you'll need Python.framework 2.3 as
well as PyObjC 1.0b1 or later. In either case, you need MacOSX 10.2 or
later.

Binary:
    http://just.letterror.com/~just/drawbot.dmg

Source:
    http://just.letterror.com/~just/drawbot.tgz

It contains an "Examples" folder with some, well, examples.

Note that you don't _have_ to use the drawing primitives I provide:
they're just thin wrappers around Cocoa's NSColor and NSBezierPath, so
you can also use the latter (or anything else from Cocoa, like NSImage)
directly.

To an extent it's intentionally sparse with features: DrawBot is being
developed as part of a course that teaches a bit of Python to visually
oriented non-programmers (ie. design students), and I don't want to
overload these people with stuff that'll confuse them; there's enough of
that in Python itself already...

DrawBot is released under an MIT-style license. It contains a more or
less reusable Python editor widget that supports syntax coloring and
smart/auto indentation.

Have fun,

Just