From: Steven D'A. <st...@cy...> - 2004-09-13 11:41:36
|
On Sat, Sep 11, 2004 at 12:59:14PM -0500, Brad Allen wrote: > 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? It sounds like you've already answered your own question. Perhaps you are looking for something that you can take to your bosses and show them a "real" [cough] application, something with grunt. Perhaps not quite Microsoft Office written in PythonCard, but something like MYOB or Quickbooks? So how about it guys, what's the biggest, most complicated application you know of written in PythonCard? > 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. That sounds less like a question about PythonCard itself and more like a question about your ability to design and manage the GUI. Unless I'm badly mistaken, PythonCard can provide all of those interface objects. > I'd be grateful for any thoughts you can provide on this. It seems to me that if you want some reassurance that PythonCard will have the grunt needed, perhaps you should knock up a quick and dirty application as proof of concept. For instance, suppose you decide that your application might have at most 5 windows with 10 text fields and 10 buttons each open at any one time. Write yourself a quick application that creates 25 windows with 50 text fields and 50 buttons each. It doesn't need to do anything except let you move from window to window clicking on buttons, cutting and pasting text, etc. That will give you some idea of the performance of PythonCard under your hardware, with a fairly high safety factor. (A factor of five.) If PythonCard fails that test, then maybe you look elsewhere, or maybe you reduce your safety factor and accept the higher risk. If it passes, then it is no guarantee that it will do what you want, but at least you now have some idea of what sort of performance you can expect. Oh, and by the way: you aren't testing your app on your shiny new dual-processor Pentium4 with 512MB of RAM, oh no, you are testing it on an old P2 with 128MB. Can PythonCard talk to your database (assuming you have one)? Knock up a quick test to see. If it fails, again you've saved yourself a lot of time. The idea is, before you commit to 1000 man-hours to build the application, commit to 30 hours to build a few test apps and run some benchmarks. Good luck! -- Steven D'Aprano Operations Manager Cybersource Pty Ltd, ABN 13 053 904 082 Level 4, 10-16 Queen St, Melbourne VIC 3000 Tel: +61 3 9621 2377 Fax: +61 3 9621 2477 Web: http://www.cybersource.com.au |