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

[Brad A. <bra...@ma...>]

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

Thanks! I appreciate the time.

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

I'm in agreement with you about those points; they are some of the 
reasons I'd prefer developing in an open standard such as Python. Of 
course, not everyone in our IT dept sees it that way. The standard 
response has been that we should do it in Visual Basic. However, 
cross-platform is a hard requirement for this project (we have over 
400 Macs that aren't going away), and I am making the case that we 
should consider Python as the standard tool for automation (shell 
scripts) and that these should integrate for our database 
environment. Folks in corporate IT depts are often suspicious about 
the benefits of open source in general, but Python is so manifestly 
robust and widely-used that I think it will prove to be no-brainer. 
In any case, the main two guys who are building the application want 
to do it in Python, and so as long the app meets our needs, I don't 
think we'll meet resistance. That's why I'm wanting to make sure the 
GUI platform is solid, because that's what the boss (and the users) 
will see.

What I'm gathering from the rest of your comments is that I'm not 
crazy just for trying to use PythonCard in a production application, 
but it is new territory and I should be prepared to encounter 
surprises, and at a minimum, expect to revamp my UI logic and 
resource files significantly with every major PythonCard update until 
the API stabilizes. On the upside, I get some training wheels for 
wxPython and a way to get up and running very quickly with an 
application prototype.

>"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 :)

Maybe people don't want to be seen as complaining about a free 
product that is so generously being donated to the public.  I will 
take your comments as an invitation to provide feedback and generate 
ideas.

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

I'm glad to hear you're ambitious about improving PythonCard. I think 
it will fill an important need for a lot of people, once it matures. 
I don't really know much about the "competition", though. You 
mentioned Boa, wxGlade, wxDesigner, etc. I'll take a look at those...

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

There's definitely a big gap right there in the open source 
offerings. Building something like FileMaker or MS Access would be an 
enormous task, though. However, neither of those products has yet 
quite "got it right". I've spent a lot of time with FileMaker. It has 
improved tremendously with the version 7 release, but it's still very 
difficult to manage as your application grows in complexity. I don't 
know much about MS Access, but I knock it because it's not 
cross-platform. In it's favor, I've heard that it's a great way to 
learn SQL because it can act as a direct front end to MS SQL Server, 
and it makes use of SQL syntax in doing so.

  If only we had something FileMaker "done right" in the form of an 
open source database product, with these features:

	* database design/layout/reporting ease of FileMaker Pro
	* the slick scriptable GUI capabilities of Runtime Revolution
	* access to SQL syntax for database interaction,
	* ability to act as front-end for remote or local SQL 
database of choice
	* bundled local "default" database engine for use "out of box"
	* API for Python, PHP, Javascript, Ruby, Perl, etc.
	* built-in IDE and default scripting language (Python!)
	* point-and-click scripts as well as "real"
	* entity relationship diagrammer
	* report generation tool similar to Crystal Reports

A product like that could be used by non-scripters as well as serious 
developers. It's a great candidate for an open-source project, 
because a database is something needed by most people who have a 
computer. It's in the same category as word processor, spreadsheet, 
and email. Hm...now that I think of it, it's hard to believe someone 
in the open source world isn't already doing this. It looks like 
OpenOffice has some database tools, but it's nothing like the pie in 
the sky I'm talking about here.