[Pythoncard-users] Re: PythonCard suitability for a project; looking for opinions

[normanwinn <nor...@on...>]

>
>
>Hi. I've been spending the last few days taking a look at PythonCard, 
>and I really like it. Kudos to Kevin, Dan, and the rest of you guys 
>for your generosity in building such a nifty open-source tool and 
>continuing to plug away at improving it. I'm a Python newbie of about 
>six months, but I found PythonCard .8 to be very approachable.  It 
>didn't take long to install and get the samples working. The tutorial 
>walkthroughs were essential to helping me learn the basics, even 
>though there were some bumps along the way (some small changes are 
>needed to update the tutorials for .8, such as the reference to 
>on_openBackground).
>
>I was looking at PythonCard as a prospective GUI tool for a project 
>at work. This project is a client-server-database application 
>designed to replace an aging FileMaker solution with a MS SQL Server 
>solution for the IT dept database. We need a full client app, not 
>just a web interface, and it needs to be cross-platform so it can run 
>the GUI on all the computers we manage. We also don't want to spend a 
>million years building it, so a scripting approach makes sense rather 
>than trying to do it in C++ or Java. So, that leaves us with choices 
>like Runtime Revolution, RealBasic, Omnis Studio, etc. Or, we could 
>go with open source tools like Perl, Python, Ruby, etc. For a variety 
>of reasons, we really like Python the best among these choices, and a 
>pure Python solution is likely to be a fairly practical and scalable 
>approach as our app grows in complexity. We've used Python shell 
>scripts in our environment to great success; it seems like a very 
>approachable cross-platform language with many virtues.
>
>The only trouble with Python is that it's not so easy to build GUIs. 
>At least, not as easy as in proprietary platforms like RunRev, 
>FileMaker, and RealBasic. We have a serious learning curve to climb 
>on that front. At least, that's what I thought until I tried 
>PythonCard. I've already been able to make a little headway 
>prototyping the client app in PythonCard, though I have a long ways 
>to go in really understanding the capabilities available in 
>PythonCard. So, I have a number of questions, but before I dig in too 
>much deeper, I'd like to get some opinions on a couple of basic 
>questions.
>
>Here is the first question: Am I crazy for considering PythonCard for 
>use in a production environment? PythonCard is obviously not yet 
>mature, and still has many gaps in the feature set, not to mention 
>bugs. On the plus side, it seems to me that when users report bugs on 
>this mailing list, they are generally identified quickly and fixed. 
>It also seems to me that if we run into problems or gaps in the 
>PythonCard feature set, we can fall back on the more mature wxPython, 
>and so have a mix of wxPython and PythonCard in our GUI logic. Also, 
>because PythonCard is open source, we can look under the hood figure 
>out what's wrong if we need to.  Is this a fair assessment?
>
>Second question: Do you see PythonCard as primarily a tool for 
>building GUIs for small, simple apps, or do you think it will scale 
>well to more complex apps, in terms of managing that complexity ? 
>The app I'm imagining will require many windows, many dialog boxes, 
>dynamically changing global menus, contextual menus, keyboard 
>shortcuts (including function keys), and validation for data entry 
>fields. It would also be nice but not required to have search results 
>that populate as the user types, layouts changing within a given 
>window, tab order between fields, drag & drop of files onto fields to 
>populate paths, user-draggable icon objects, and tabbed interface in 
>some windows.
>
>I'd be grateful for any thoughts you can provide on this.
>

I'm a little disappointed you didn't get a reply. I, like you, am 
playing with Python with almost the same hopes and intentions. I have a 
large Filemaker project which I could probably sell if I knocked it into 
shape. I understand that others have not replied as they are interested 
in the nitty-gritty of PythonCard. However, your questions, while 
directed at the PythonCard list, are at the heart of whether and when 
the big move from Windows and Mac platforms will take place. I have just 
been playing with Delphi as a magazine I bought had a screen capture 
project using it. I found, just like when I used Delphi previously, that 
when I want to add functionality, it invites me in. Why? There is 
extensive help, there are legion examples to be cut and paste. The IDE 
is consistent. The app builder just works. It is fast.

Now comes the difficult bit. Difficult as it feels wrong to criticise, 
however gently, those who give of their time and expertise freely. 
First, why is Python so good? The simple answer is that there is a 
controlling influence. Guido the guide (who has a sword up his sleeve).  
I think in this surmise lies the reason that going about using Python 
for large, professional projects does not just 'invite you in'. In this 
area there is no arbitrator, no coordinator. I expect there are strong 
reasons that there is a 'Boa Constructor' project, a 'PythonCard' 
project, a 'Glade' project and many, many others. It feels, from the 
outside looking in, that all these riches combined could give us better 
than Delphi. And if we had that the world would move to Python and the 
writing would be on the wall for the evil empire. Instead the latter are 
issuing free versions of the .net tools, Novell fosters mono.net making 
it cross platform - the empire is fighting back and has formidable weapons.

There may be an answer at hand. What could unite the Python forces is 
money. Money to free the developers from other constraints. Where would 
the money come from? I would suggest the EU. They throw large sums of 
money around for much less useful things. If Guido the guide could be 
enrolled to take on not just the language but a standardised tool set 
and project builder then the EU would get an unheard of return on 
capital invested,

Norman Winn