[Edu-sig] would you use PythonCard?

[agauld@crosswinds.net]

On 30 Aug 01, at 11:45, Kevin Altis wrote:
> >     GUI builder.  Yawn.
> PythonCard is more than a GUI builder, but even so, why would you 'Yawn'?

Coz there are lots of GUI builders already?
And GUI builders for a language like Python are not so productive.
In a language like VB or Delphi (which I personally love to bits) 
they are near essential but Python operates at a higher level 
and used in conjunction with an interpreter session a GUI 
builder is pretty much redundant for anything but big complex 
GUIs.

> I'm curious what you currently use with Python. 

IDLE and Pythonwin sometimes. 
But mainly just a DOS box and a vim editor...

> GUI tools for commercial languages, but everything for Python is pretty
> limited either by the underlying toolkit (tk) 

Thats a common misconception but in fact Pythons dynamic 
nature means you can construct the GUI piece by piece from the 
Python prompt. Changing positions by just unpacking and 
repacking as you go. It does help to sketch out the general layout 
first but thats true of VB etc too. But python is far more dynamic 
that the layout tools in VB or Delphi etc.

> the runtime or development tools. More importantly, most of the framework
> tools take a monolithic approach which is fine for large team projects, 

Huh? Most take (or at least allow) a very OO approach that 
encourages separate developments - either of individual 'super 
widgets' or of discrete 'windows' or dialogs. In fact I'd say VBs 
approach is more monolithic than Pythons. Python does require 
you to work differently - more like a Smalltalk project than a 
VB/Delphi one.

> is really hard on the beginner or infrequent user. 

This is true - power has its own penalties.
Same is true of vim and emacs as editors.
Maybe PythonCard has the better approach for occasional users.

> None are geared towards RAD for simple projects 
> which should be completed in fifteen minutes 

This is totally wrong. Python and its GUI toolkits
(Tkinter and wxPython are the ones I've used) are very much 
more appropriate to real RAD than most GUI Buildr based 
tools. Python keeps the focus on the function of the program 
not the appearance. VB might be prettier initially but Python 
will work better, faster.

> because Python is a magical language missing the framework and environment
> for doing normal desktop applications and utilities. 

No, Python just has a different approach. Try playoing with the 
Smalltalk workspace for a while, or talk to some Smalltalk 
programmers and see why Smalltalk is considered one of 
the most productive RAD tools around. Then do the same 
things in Python...(but without the class browser :-( )

> sounds defensive, but I really would like to hear your opinions.

Not at all. Its a common perception for those coming from 
"traditional", aka GUI based RAD tools. Once you get used to 
Pythons approach its not really that much slower and nearly 
always delivers better core functionality.

> 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.

Which are laudable aims and to be encouraged.

> Eventually, there will be an environment, so that you can dynamically 
> add and edit widgets, scripts, etc. 

But I can already do that with Tkinter etc now. Its called the 
Python prompt...


much like HyperCard. In addition, like

> just want to use PythonCard for simple database-type apps, little to no
> coding will be required. 

Could you expand on this aspect please?

> fairly limited) different now is that the widget usage is basically like
> using any other Python object. 

How is this different to Tkinter?

> 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, 

Resource files are one way of doing this and Parrot 
tries it for Tkinter... 

But Python supports this out of the box by simply defining 
the app code in a separate moduile and binding its 
functions/methods to the GUI elements. This is normal 
best practice.

And its all dynamic binding in Tkinter - you can even change the 
bindings mid program if you really want to.

> '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, 

But how do you change the behaviour of that during program 
execution? Thats less dynamic not more... (Yes, you could 
create a new function and assign it to on_btnRun_mouseClick 
via a lambda or using nested scopes I guess)

> you can even create widgets dynamically and they'll bind to
> any appropriate handlers you already have.

I'm not convinced having to write a single line of binding code 
is that big a deal...
 
I think PythonCard sounds like an interesting developnment.
Like HyperCard its probably a better approach for occasional 
users and, like HyperCard, probably will have less attraction 
for 'power users'.

All just my opinion of course.

Alan g.