[Edu-sig] would you use PythonCard?
agauld@crosswinds.net
agauld@crosswinds.net
Fri, 31 Aug 2001 23:43:41 +0100
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.