PythonCard, ease of use, and the GUI problem/opportunity/niche

[Tim Churches]

Ron Stephens wrote:
> 
> Bingo! Boy, oh, boy, do I agree with you on this. I think you hit the nail right on the head.
> 
> Building a gui now using Python, compared to using VB, really sucks. Yes, it's that bad.
> 

My experience with VB5 on a fairly complex application was that it was
easy to lay out the forms and bind the data-aware controls to a
database, but as soon as you attempted anything fancy you started to get
into trouble, either in terms of maintainability, memory and other
resource consumption and quite often outright crashes. The semi-OO
features in VB6 might have improved matters - I don't know because I
subsequently discovered Python.

My limited experience so far with wxPython is that the screen design is
definitely more fiddly than with VB, and binding controls to a database
is a more manual process (more work), but because everything is done
with Python, there is a strong tendency for things to just work, first
time. Of course, maintainability is vastly better than VB, mainly due to
wxPython's insistance that everything is a subclass of the basic
wxPython classes.

> Whichever reasonably easy to use language (right now I'm thinking either Python, Ruby, or a yet-to-be created
> language) first gets an open source gui builder built on top of it that is as easy to learn and use as VB will
> dominate the world.

I would suggest that world domination will only come when there is an
open-source application which matches the ease of use and, given that
ease-of-use, very broad capabilties of MS Access, which is MS Window's
killer app in my view. To programmers, Access is just "dumbed-down VB" -
indeed it is, but it is that dumbing-down that makes it so wildly
popular - there must be orders of magnitude more MS Access databases in
daily use than there are VB apps - at least that is my experience. Most
of those Access application are, to the eyes of an experienced
programmer, a complete dog's breakfast, but the alternative is having
end users managing their data in Excel spreadsheets, which is even
worse. But Access is also powerful - you can create some very
sophisticated, elegant, easy-to-maintain and powerful application in
Access which are almost completely code-free (and therefore almost
self-documenting). Indeed, I regard Access so highly that it even goes
some way to assuaging the sins and excesses of Microsoft (but not enough
for them to be forgiven!).

> 
> It must, in my opinion, be as easy to use as VB for building simple input and output forms. That's the key. It
> doesn't have to be any more powerful or anything else. Just easy. This is a crying out loud need that anyone
> can see; someone will solve it, I am sure. It's too big an opportunityto be forever ignored. Unfortunately, I
> am beginning to hae my doubts that it will be a Python-based solution. I sure hope I'm wrong.
>

The Recall product being developed by The Kompany looks promising - it
is an Access clone (that's good), uses Python as its scripting language
and provides automated binding to the popular open source SQL engines
and to dBase files. However, it has a long way to go before it is as
slick and as capabable as Access, and is currently limited to the KDE
environment (although it is being ported to Windows). However, it is not
free, and for Windows users who already have MS Word and Excel on their
PCs, the choice between paying one or two hundred dollars for Access
versus a bit under $100 for Rekall is a no-brainer, given the widely
available support and huge knowledge-base which Access has built up over
the last 10 years (yes, it has been around in it current form with only
cosmetic and other minor changes for that long). For an Access
alternative to gain a foothold, it needs to be cost-free and very easy
to install, so that people will at least evaluate it as an Access
alternative.
 
> The only hope that I know of right now is PythonCard, only a six month old project led by Kevin Altis. I
> really admire Kevin and his team and I admire this project. I think they are ace coders (especially Kevin )
> who are capable of doing what needs getting done. But I am afraid they will miss the mark, partly for the same
> reason as Zope has its detractors, namely, lack of good, easy to use documentation for learning and using the
> language.
> 
> Now, I know it's not fair to compare Pythoncard to Zope, as PythonCard is only six months old and pre-alpha,
> for heavens sake ;-))) But when you love something, ..
> 
> I am really like a cranky old uncle that only dotes from afar on a precocious child. I have nothing to do with
> PythonCard, have contributed nothing, etc. But I admire it from afar like a doting uncle.
> 
> But I haven't tried to use PythonCard in many weeks, a fact I hope to remedy this weekend. But I stopped
> trying because, while I could see the brilliance of design and implementation, and potential for ease of use,
> I couldn't get much farther due to lack of documentation.
> 
> What's a resource file anyway? What's an application framework? Yes I'm a clueless newbie, but that's what the
> winner in this battle must do, create something as easy to learn and use as VB is for a clueless newbie. For
> now, unfortunately, I find it easier to use Tkinter because I have tutorials, online documentation, and even
> books. PythonCard actuall seems harder to me as it stands.
> 
> Maybe some of us could actually *help* create some documentation for PythonCard???? It's home page is at
> SourceForge at http://pythoncard.sourceforge.net/
> 
> So go check it out. I really believe this is important. I'm going to try to use it this weekend. Lets discuss
> it, then, OK?????

The main things which PythonCard needs are:

a) A drag-and-drop form editor (I believe this is being worked on)
b) Automated bindings of data-aware controls to underlying databases.
c) A drag-and-drop SQL query editor.
d) A banded report writer like Access or Crystal reports.
e) A really easy installation routine which handles the database
installation/adminstration as well.
f) Excellent documentation.

Not a small ask, but that's what it will take to become a real
competitor to Access.
Most of these things are being worked on in one part of the Python world
or another, but I suspect it will take several years and a conscious
effort at co-operation between various projects for the various parts to
make a whole which can rival and possibly outstrip MS Access.

Tim C