Re: [Pythonmac-SIG] XCode for OS X 10.5?

2010-06-25 Thread davelist

On Jun 25, 2010, at 9:18 PM, Skip Montanaro wrote:

> Sorry to ask a non-Python question here, but I need this to get my laptop 
> rebuilt
> so I can do stuff again.  I lost the disk on my Macbook Pro which Apple kindly
> replaced, however my backups were partially toast, so I had to reinstall OS X
> from scratch.  (Luckily /Users was viable.  Whew!)  
> 
> I can't find a version of XCode which works with Mac OS X  10.5.  All Apple 
> will
> show me on their dev site is XCode 3.2 which requires Snow Leopard.  I can't
> build a dang thing - no make or gcc for instance.
> 
> Any pointers appreciated.
> 
> Thanks,
> 
> Skip Montanaro


Try http://connect.apple.com

You can find older versions there.

Dave

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG


Re: [Pythonmac-SIG] Shortcut for IDLE on Mac OS X (LEOPARD)

2009-10-08 Thread davelist


On Oct 7, 2009, at 7:35 PM, Christopher Barker wrote:


Ben Golding wrote:
You should be able to put this in a double-clickable file by  
putting that string in a file called, say, IDLE.command and then  
making it executable.  Files ending in ".command" are recognised by  
Launch Services as shell scripts (I believe).


Has no-one made a nifty utility to make a *.app bundle from a shell  
script? That would seem like an obvious utility to want...


-Chris


You can do that with Automator by choosing the Application template,  
choosing the shell-script action, and then saving it.


Dave

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig


[Pythonmac-SIG] correct way to create a PyObjC application

2008-11-15 Thread davelist


I've done a little bit Cocoa programming using Objective-C and tried  
PyObjc back under Xcode/IB 2.0, but now I'd like to try PyObjc with  
Xcode/IB 3. Using a mixture of documentation, here's what I've come up  
with. Can someone please let me know if there's anything wrong with  
this process or if there is a much easier way (I'm not complaining -  
this seems pretty simple to me) to create a simple PyObjc app (no  
bindings, or existing controller classes, etc.) using the Leopard  
System python/pyobjc (i.e., the python that comes with Leopard).


1. In Xcode 3, create a Cocoa Python Objc Application
2. add a new Python file that will be the controller
3. click on MainMenu.xib to open IB
4. create interface
5. drag a NSObject to IB MainMenu.xib window (I believe this is  
referred to as the Doc window)

5. in the IB Inspector window do the following
5.1 change the Class Identity to the Python controller class I just  
created
5.2 add outlets for the widgets I need to access in the Class Outlets  
section
5.3 add actions (no underscores in names, end in a colon) in the Class  
Actions section
6. Control mouse drag from Controller in Doc Window to each widget and  
set the outlet
7. Control mouse drag from Buttons, etc. to the Controller and set the  
action

8. in Controller Python file:
8.1 add a line for each outlet right under class definition that looks  
like: outletName = objc.IBOutlet() (this will allow methods to access  
the outlet as self.outletName
8.2 create methods that match action names changing colon to  
underscore (i.e., def buttonPressed_(self, sender); one web page said  
add @objc.IBAction above those methods but that didn't seem necessary)
9. in generated main.py, add import statement for my Python controller  
file

10. Build and Go

This seems to work for me and if I tell it to build a universal app  
and use the Release build, I can even copy the release build .app to  
other machines and run it.


Thanks,
Dave

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig


[Pythonmac-SIG] Python TkAqua, Tkinter bug

2007-11-02 Thread davelist
I am not certain where the problem is or who to report it to, but  
there is a bug in TkAqua, Tkinter, or possibly OS X's windowing  
system. I am using a simple module on top of Tkinter for teaching an  
intro programming course. When I click the mouse in the Tkinter  
window, it often reports the wrong coordinates for the click most of  
the time. If I use idle and first click on the Tk Console window and  
then in the graphical window it seems to work. If I don't click in the  
Tk Console window or start Python from the Terminal, it almost always  
reports wrong values.

I am running Leopard now and tried both the built-in Python 2.5 and  
installing the version from python.org. Some of my students who are  
using Tiger report the same issue - I don't recall problems last year  
when using this on Tiger, but it's possible. On Windows, the  
coordinates are always correct.

The graphics.py module built on top of Tkinter is available at:

http://mcsp.wartburg.edu/zelle/python/

A simple example that shows the problem is:

from graphics import *
win = GraphWin('test', 800, 800)
pt = win.getMouse()
print pt.getX(), pt.getY()

After clicking in the top left corner, it is clearly the wrong answer  
(it should be near 0, 0 depending on how accurate your click is).

Any ideas on where the problem is, who to notify, etc.?

Thanks,
Dave


___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig


Re: [Pythonmac-SIG] Why Do I Explicitly Need MacPython

2006-09-25 Thread davelist

On Sep 25, 2006, at 5:08 PM, Russell E. Owen wrote:



>
> I see what you mean about different installations. I think the  
> following
> might work better:
> - Always modify _tkinter.so to point to Tcl/Tk 8.4 in
>/Library/Frameworks.
> This will fall back to the built in /System/Library/Frameworks if the
> user has not installed an 8.4 of their own.
>
> It avoids a few of the issues you bring up and is simpler and more
> robust than what I originally suggested. Advantages:
> - All installations would be the same.
> - If the user installs a new Tcl/Tk after installing Python, it  
> would be
> used (unless it's 8.5, which would not be safe to try with Python).
>
> It still does not address your concern than a user might accidentally
> have a  Tcl/Tk that they don't want to use. I'd personally be  
> happier if
> users could  easily upgrade their Tcl/Tk (since the installed one  
> is so
> bad), so I see this as more of an advantage than a disadvantage. Users
> aren't going to typically  install Tcl/Tk unless they want to use  
> it, I
> think. Still...I'm sure you've seen more requests for help than I have
> over the years.
>
> I'm not keen on including a Tcl/Tk for several reasons:
> - Which version would you use? Even 8.4.11 has some important known
> bugs, and 8.4.13 has different ones (at least one of which is very  
> nasty
> for my application, so I stick with 8.4.11 for now).
> - If a user wanted to upgrade their Tcl/Tk, what would they do? The
> answer is easy if we use the version of 8.4 found in /Library/ 
> Framework
> (if any).
> - It can be tricky to add needed additions (my app uses the
> "snack" sound library, for example). A standard Tcl/Tk makes this much
> easier (and in fact  ActiveState Tcl/Tk already includes all additions
> most folks would want).
> - There is no universal Tcl/Tk yet (though one is planned). I  
> personally
> don't want to try to build one.
>
> So my personal suggestion is that we modify _tkinter.so using
> Bob Ippolito's recipe unchanged (no fancy script that hunts for an
> installed Tcl/Tk). It will be completely compatible with the built in
> Tcl/Tk but gives any real users of Tcl/Tk (anyone who isn't just  
> writing
> "hello world") a trivial way to get a decent version.
>
> -- Russell


I'm very interested in this and would be happy to help with testing.  
I teach Python at the college level using John Zelle's Python book  
(it uses Tk for simple GUI programs). Most of the programs run fine,  
but some of the more complex ones crash intermittently within Tk. The  
same program seems to run fine on Windows using 2.4.3 although it  
does crash intermittently on CentOS 4.3 within Tk.

In the meantime, are you saying the simplest solution for my students  
with Macs is to use ActiveState (some have G4 laptops and some have  
Intel based laptops)?

I have a G5 running 10.3.9 at work (IT isn't planning to upgrade yet)  
and a G5 running 10.4.x at home so I'll be happy to test on both of  
those.

Thanks,
Dave

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig