This was originally an e-mail posted to the pythoncard-users mailing list


I've been thinking about PythonCard a lot recently since discovering it at the weekend, so here (in no particular order and probably of no particular interest to anyone but myself) are a few of the thoughts I've been having.

PythonCard as a Python "Killer App"

Zope is frequently described as Python's Killer App. The problem with Zope is that it has a very steep learning curve, and it's quite easy to give on Zope and look elsewhere before the moment of enlightenment (when Zope's whole design suddenly makes sense) occurs. For me, the moment of enlightenment with PythonCard occurred within 5 minutes of starting Dan Schafer's walk through. I had never written a GUI application before but everything made perfect sense - I especially liked the way the GUI layout and application logic were separated without me even having to think about it. Python has a reputation as a very easy language to learn, and I think that this combined with PythonCard's ultra-simple GUI creation tools (and a lot of advocacy / marketing etc) could lead to a fantastic tool for new programmers. VisualBasic may do the same kind of thing but PythonCard isn't held back by VB's truly revolting syntax (imo at least). Could PythonCard become a new Killer App for Python aimed at new programmers (unlike Zope which has quite a high barrier to entry)? I have no idea but it's a nice thought :)

PythonCard + XMLRPC = a new way to manage a web based Content Management System

There have been some excellent articles floating around recently about how chronically unsuited to writing applications HTML really is. This column by Anil Dash is a good example:

The problem with writing an application to interface with a CMS is that the structure and layout of a site changes frequently. Even the best designed site structures will occasionally add a new database field or alter in some minor way the way the site is structured. As a result, writing a custom application in a traditional programming language is a bad idea - the moment you add a new field to your news story database table you have to update the application.

PythonCard changes this by making adding a new form element as simple as dragging and dropping in a new textarea widget. By combining a well structured PythonCard application with a web service interface (I like XMLRPC but SOAP would work just as well) to your CMS (as I did with my first PythonCard application ScratchPad) you can quickly and easily create an application that can administer part or all of a CMS. If you change the CMS changing the application should be simple. Using XMLRPC or SOAP gives you full flexibility over what language to implement the actual CMS in - my example was written in PHP but the XMLRPC server made integrating it with PythonCard a breeze.

Something else that popped in to my head was the idea of a single description for an application interface that allows the web interface (HTML forms) AND the PythonCard application interface to be generated automatically. This would allow web application builders to create one description and instantly have web and PythonCard interface with no extra work. I doubt that this would be feasible thanks to the fundamental differences between a GUI app and a web app (which is restricted by the request/response nature of HTML) but it's an interesting concept.

PythonCard feature requests (related to resizing documents)

The biggest problem with my current ScratchPad application is that if the user resizes the window it looks rubbish (none of the elements resize to fit). I looked at some of the sample code that resized properly and saw that the standard method of doing this was to call wxPython directly. Unfortunately this breaks the whole idea of application logic staying separate from the GUI layout. An option to "lock" my application and prevent the user from resizing it at all would be nice (I'm sure this can be done using wxPython but I didn't have the slightest idea how to do it).

The ideal solution would be for some kind of method of utilising different layout managers from within the PythonCard resource editor. I understand that this is a very different features to code (and design), but if it could be done in an elegant way it would hugely improve the usefulness of PythonCard for developing more complex applications. Would it be possible to implement a simpler resize-friendly feature by allowing user's to set the width / height of elements in percentages (as is done in HTML)? In fact, there are probably quite a few box-model methods from HTML and CSS that could possibly be used in a system like PythonCard that may not have been explored before in the traditional world of GUI layouts. That said I have virtually no experience of GUI layout techniques (other than a Java Swing lecture or two) so chances are this has been tried before.

If you've read this far thanks for making it and I hope I haven't wasted your time :)


Simon Willison

GeneralMusingsOnPythonCard (last edited 2008-03-11 10:50:23 by localhost)

NOTE: To edit pages in this wiki you must be a member of the TrustedEditorsGroup.