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.