RE: [Pythoncard-users] Re: hoping for more input

[Kevin A. <al...@se...>]

Thanks for the comments!

> From: Rodney Somerstein
>
> Message watcher functionality is definitely useful. I think that in
> general, the command line should be hidden as much as possible from the
> user in PythonCard. Being able to bring one up only as needed is
> definitely
> useful, though.

Originally, the idea of the shell was to give us a HyperCard-like message
box, but multi-line. Once Patrick had PyCrust working it made sense to
utilize all the power available. It is extremely common for even new Python
programmers to use a Python shell, so I don't feel it is a bad thing to have
a full shell rather than a simplistic input/output mechanism like the
HyperCard msg box. An important distinction right now is that the shell is
only available if one or more of the "Debug" windows is requested at
startup. In the future, the framework could be changed so that those windows
could be invoked later.

It is important to not confuse the shell with working from the command-line
prompt of MS-DOS or Unix, also referred to as shells. You might start a
PythonCard program Windows 2000 as:

  C:\python\PythonCardPrototype>samples\proof\proof -s

or Windows 98

  C:\python\PythonCardPrototype>c:\python21\python samples\proof\proof.py -s

but all the other interaction would be from the runtime "Shell". If you look
at the turtle and resourceEditor samples, you'll see the trick at the bottom
for having an app invoke a Debug window like the shell regardless of the
pythoncard.config.py, pythoncard.user.config.py, or command-line option.

    # now force the shell to be enabled
    PythonCardPrototype.config.Configuration().setOption('showShell', 1)

> I actually think that dependence on the command line is one of Python's
> weaknesses. It makes things easier when launching from Unix. But, it is
> much harder for users to follow if they are used to Windows or Mac OS.
> Given this, PythonCard should be a double-clickable application
> that can be
> launched easily by a user and then let them create applications easily
> using PythonCard as the scripting language. If someone has to start the
> whole Python environment to run their applications, you will lose many
> potential new users.

If the association has been made between the file extensions (.py, .pyw) and
the python executables, then you can open an application in Windows using
the Explorer and just double-clicking. This should be the default with your
installation. I don't know the variations under Unix, but I'm pretty sure
you can do something similar (help me out here Unix folks). There are two
distinct flavors of Python on the Mac right now that are being merged. One
is more of a Mac classic environment and the other is more like Unix. In
both cases, I believe a script can be launched by double-clicking, but again
I'm not using the Mac these days, so somebody else will need to
confirm/correct me.

> Similar to the above, PythonCard needs to provide a way to deliver easily
> launchable and distributable applications. If it doesn't compile
> to Java or
> some other language, then there needs to be really good documentation
> describing how to create a standalone application on each supported
> platform. It isn't sufficient to expect the user to figure out
> how to do it
> on their own.

Having a standalone installation for a PythonCard application that doesn't
require the user to already have Python, the wxPython, PythonCard, and
PyCrust packages is not a simple problem to solve. This is probably doable
using py2exe under Windows, but nobody has tried yet that I know of. It is
more complicated under Unix and the Mac, but there are possibilities. One
suggestion for the app itself is that we use a zip bundle similar to a Java
.jar/.war file to package up all scripts, resource files, sounds, images,
etc. into one file. With the write header, this could be double-clickable.
We probably won't explore these issues until much later in the project
cycle.

Once we figure out how to do it, automating the process shouldn't be a big
deal.

ka