[wxPython-mac] Re: [Pythonmac-SIG] Wanted: working example of CFBundleTypeRole Shell

[Kevin Ollivier]

> Right now I'm using KDE on Linux, and it works great: you can have a
> primary association that will launch and app on clicking, and any number
> of secondary associations that you can choose by right clicking. YOu can
> , of course, also specify the app when you right click.
>
> Enough ranting. I had hoped OS-X would have come up woth something
> better. IN any case, if you have a one-to-one association with a *.py
> file, I certainly hope the OS gives you a way to choose that
> association. Differnet people are going to want different things.

I agree with this as well. There are rumors that OS X 10.2 will introduce an
"Open With..." context menu. (Hoping!)

> I do like the idea of the defaults being: *.py--editor of your choice
> (maybe defaulting to the IDE), and *.pyc--The interpreter. This fits
> well with all other compiled language development: the source code is
> edited, the compiled code is run.

This I don't agree with, simply because people generally distribute the .py
file instead of the .pyc file. On Win and Linux, this is not a problem - by
default double-clicking on a .py file compiles and then runs the script. It
treats it like an application, as Kevin Altis mentioned earlier. I think we
need to justify why Python should behave differently on Mac if we want to
change this behavior. I think it would be detrimental because the average
Python user would have to open most scripts in the IDE before running them
the first time, and know the difference between .py and .pyc to avoid doing
this subsequent times.

> I suppose we still  have the question of whether it should bring up a
> terminal window or not, but maybe *.pyw would make sense for supressing
> that, and being compatable with windows. Another option is to do what I
> always do on Linux: if I want a terminal window, I start the script form
> a terminal window.

The default behavior on Windows is to have a terminal window for .py, and
suppress it with .pyw. I think this works. We may need to control
Terminal.app to make this happen... I'll have to look into it. However, I
have to say that the terminal window issue on Windows is not very reliable
because the shell closes as soon as execution stops - which isn't very
helpful for debugging purposes. (Nothing to do with Python, a dumb default
in Windows.) As a result, on Windows I always open up a DOS window when I
want to view terminal output as well. On OS X, you can use the Console.app
utility to view any stderr (and stdout?) messages that occurred since the
start of the session, so anyone wanting to debug has this option as well.

> On *nix, by the way, the distiction between a source file and an
> executable is whether the executable permission bit is set. If it is,
> then typing it on the command line (or clicking on it in a file manager,
> depending on the file manager, will run it. Perhaps this could be used
> by OS-X as well, though I still think the File manager should provide an
> easy way to make the choice each time you click the file.

I wouldn't want to rely on this, simply because as people share files
between platforms it would not reliably keep the executable bit set. (Say it
was developed on Windows, for example.) However, I think when you use the
Terminal in OS X, it behaves as you described, so *NIX friendly people can
still have that behavior if they so desire. =)

Kevin