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

[Kevin A. <al...@se...>]

A long message deserved a long reply, so...

The primary benefit of Open Source (OS) is not the cost of the 
frameworks, tools and applications. The key issue on whether to use OS 
or proprietary tools is control. In terms of Python you know that the 
language isn't going to go away and it will continue to work on all 
major platforms for a long time, which you can't say for some of the 
smaller proprietary company solutions. wxWidgets and wxPython are 
getting better and much better supported financially each year, 
especially with large OS projects like Chandler funding development; 
Robin Dunn is a full-time employee of the OSAF. Whether you need all 
the control that an OS solution gives you is a business decision that I 
can't answer for you, but in general I think it is the right direction.

On Sep 11, 2004, at 10:59 AM, Brad Allen wrote:

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

You are correct that the proprietary tools still have the edge on 
integration of the the IDE/design environment and that is unlikely to 
change in the short-term, say the next six months to a year. There is 
simply more money and manpower, project Q&A, feedback from customers, 
etc. There are quite a few people that work part-time on PythonCard, 
but it isn't like anyone is full-time or working towards a specific 
project feature set or ship date, it just evolves as people get time 
and their interests motivate them to contribute.

"Customer feedback" on PythonCard is actually pretty minimal 
considering that there are 260+ people on the mailing list. Most of the 
discussions on this list are support-related, either bugs or people 
trying to figure out how to do something within PythonCard. I think I'm 
generally pretty responsive to issues that people bring up, but if 
nobody is talking about design, UI features or other things they want 
to see in the project, then I just move at my own pace and treat myself 
as the customer :)

I would love for us to get to the point that PythonCard had a really 
nice environment so that someone could write a book "PythonCard for 
Visual Basic Users" or something like that, but realistically the 
environment is just too clunky right now, so maybe we'll get there in 
2005.

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

That's pretty fair. I've said that the current goal is to have a 
PythonCard 1.0 release not long after wxPython 2.6 is released, 
hopefully by the end of this year or early 2005, depending on 
wxWidgets/wxPython. Until then, every release of PythonCard will track 
the latest wxPython release and you can expect some API or resource 
file format changes between releases. All of the changes will be 
documented, but you should expect to have to update your code with each 
release. That shouldn't be a big deal for a single project given that I 
keep all the samples and tools up-to-date with each release and that is 
probably a lot more code to manage than your own project <wink> By 1.0, 
I mean that the framework API will be "done" and future 1.x releases 
won't break backwards compatibility. The tools will continue to change 
and improve with future 1.x releases since that doesn't impact user 
code.

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

At a minimum, you will be able to bang out a hell of a prototype that 
works on Linux, Mac OS X, and Windows. You will almost certainly have 
to resort to using raw wxPython code for your project, but everything 
you describe above is doable within wxPython and most with plain 
PythonCard. PythonCard definitely has a target audience and type of 
application that is generally smaller than what you're describing. It 
is difficult to simplify wxPython, as PythonCard attempts to do, and 
not lose some functionality at the same time. You may find at some 
point that you simply want to move to using pure wxPython, but then the 
transition from PythonCard to that should be relatively easy. People on 
the wxPython-users mailing list are working on much more complicated 
app solutions, including database apps. You will probably want to take 
a look at things like:

http://dabodev.com/about
http://www.gnuenterprise.org/

as well as evaluate Boa, wxGlade, wxDesigner, etc.

On the topic of database solutions, I'm extremely interested in that 
application space, though I don't really do much with databases, 
especially SQL databases day-to-day. In particular, I would like to 
hear about features that products like FileMaker Pro provide that are 
needed for an OS tool that users could transition to without feeling 
like they are taking a step backwards.

> I'd be grateful for any thoughts you can provide on this.
>
> Thanks!
>
> Brad Allen
> Omnicom Management Services
> Dallas, TX

ka