[Edu-sig] would you use PythonCard?

Kevin Altis altis@semi-retired.com
Thu, 30 Aug 2001 11:45:10 -0700


> From: fcy@acm.org
>
> I looked into PythonCard after your first announcement.  Here's the
> impression I got:
>
>   + Visit site on SourceForge.  Look at "screenshots" page.  Seems to be a
>     GUI builder.  Yawn.

The screenshots pages don't show all the samples and they don't show any of
the runtime windows like the Shell, Message Watcher, Property Editor, or
Namespace Viewer. Hopefully, those pages will be beefed up soon.

PythonCard is more than a GUI builder, but even so, why would you 'Yawn'?
I'm curious what you currently use with Python. Obviously, there are great
GUI tools for commercial languages, but everything for Python is pretty
limited either by the underlying toolkit (tk) or there are costs involved in
the runtime or development tools. More importantly, most of the framework
tools take a monolithic approach which is fine for large team projects, but
is really hard on the beginner or infrequent user. None are geared towards
RAD for simple projects which should be completed in fifteen minutes to an
afternoon while still working for larger projects.

The question becomes what would be exciting? I jumped on the PythonCard idea
because Python is a magical language missing the framework and environment
for doing normal desktop applications and utilities. I know this probably
sounds defensive, but I really would like to hear your opinions.

>   + Follow link to "Samples 2" page.  Now these "turtle" applications
>     look more interesting.  But there's no hint as to how one develops
>     such applications.

Yet another need for more documenation. There is actually quite a bit in the
turtle directory, but it could use more.

>   + Follow link to "requirements" document.  It seems to sketch GUI
>     elements to appear in the user interface.  But I get no feel for
>     what PythonCard really _does_.

Good point. The requirements document should go away. It filled its original
purpose which was to get us to the first pass at a prototype, which we've
done. We're still enhancing the prototype, but we're beyond the initial
requirements, which we needed when we started coding about six weeks ago.

PythonCard is many things, but right now it is an application framework and
a set of runtime tools to enhance and aid programming in PythonCard.
Eventually, there will be an environment, so that you can dynamically add
and edit widgets, scripts, etc. much like HyperCard. In addition, like
HyperCard the framework will support transparent data storage, so if you
just want to use PythonCard for simple database-type apps, little to no
coding will be required. Part of what makes the framework (which is still
fairly limited) different now is that the widget usage is basically like
using any other Python object. More importantly, resource files are
supported, so you don't have to mix widget descriptions in with your code
and all the event binding is dynamic, so if you have a Button widget named
'btnRun' and a field named 'field1' in your app and you want to do something
in response to a mouseClick on that button, you simply add a method

    def on_btnRun_mouseClick(self, target, event):
        self.components.field1.text = 'hello'

That's it! No event tables, no callback definitions, no window handles, no
initialization, you can even create widgets dynamically and they'll bind to
any appropriate handlers you already have.

> So, I wait for the project to mature a bit and provide more useful
> information about its goals.

The project is still 'alpha'. The reason I'm actively promoting it is to
make sure that it has an audience once it goes beyond alpha. It is still
usable today and will continue to be, but the API changes as features are
added, changed, or removed and we turn wxPython specific calls into wrapped
PythonCard calls. Consequently, nobody should be building a big project
today based on PythonCard and they should realize that small changes might
be necessary in any code they write, though it might be a simple
find/replace kind of change. All the samples are kept up to date with the
current framework as changes to the API are made.

Thanks for responding,

ka