Re: [Pythoncard-users] Who is PythonCard's intended audience?

[Alex T. <al...@tw...>]

Kevin Walzer wrote:

> I'm very interested in wxPython as a development language, because it's
> free/open-source and also because of the number of different tools it
> supports--including PythonCard. I've been lurking on the PythonCard list
> for some time. I'm also working on learning wxPython itself, mainly by
> following the various tutorials at the wxPython wiki and also tinkering
> with the code samples that come with the wxPython distribution.
>
> That experience, while hardly making me an expert, has made me a little
> puzzled about who the intended audience for PythonCard is. Is PythonCard
> aimed at people who want a RAD environment for wxPython, 

yes

> or for peole who perhaps want to dabble a bit with development but not 
> try to learn
> wxPython whole hog?

yes

> I'm asking not to be contrarian, but out of genuine curiosity. While
> wxPython itself is big and my progress with it has been fairly slow, I
> don't feel that wxPython is terribly difficult in itself. As well,
> PythonCard only supports a subset of wxPython widgets and does not
> provide a true drag-and-drop development environment. 

what's your minimum definition to be a "true drag-and-drop" environment ?
If you mean a full "integrated live environment" (e.g Hypercard, 
Metacard, RunRev, etc.) then it's not, and never will be, that. But then 
- neither will any other Python based approach, and very few others either.

If you "simply" want an environment where you can layout and 
characterize the graphic elements, with reasonable integration with the 
associated code, then I think PythonCard is fairly close.  If you 
haven't tried it, try the experimental resourceEditor (see earlier on 
the list, or it will be in CVS soon - it adds a number of features that 
I think are useful.

Only supporting a subset of wxPython widgets is, I believe, a deliberate 
and important strategy. There are so many of them that it's easy to be 
overwhelmed by the choice, or to spend too much time learning them all 
(and then forgetting about them before you ever need them). I believe 
that PythonCard *should* support the 30% of wxPython widgets needed to 
handle 90% of straightforward applications.

> So, does PythonCard provide the expected gain in ease-of-use and 
> development
> speed that comes with giving up the power (and complexity) of the full
> wxPython environment?

Yes.
Of course, you don't give up the power of wxPython. It is possible, and 
in most cases practical, to use directly those wxPython widgets that you 
need and which PCard doesn't support. Of course, it means that you need 
to go through some of the learning curve - but you don't need all of it, 
and often you can avoid the tedium (my opinion) of programming in 
wxPython for a large percentage of your application.

> Disclosure about my own background: I've done "get-my-hands-dirty"
> development work, coding a few non-trivial applications in Tcl/Tk
> completely by hand, and I've also done some "quick-and-dirty"
> drag-and-drop development with Apple's Xcode tools (AppleScript
> Studio--slick and free, but not open-source). So, I've seen both ends of
> the spectrum, and am trying to understand where PythonCard fits in.
>
> I appreciate the perspective that others can provide, especially about
> the good points of PythonCard that I am perhaps overlooking.

I've written a number of small applications in Pythoncard - mostly for 
personal use, some used by myself and a few other people. In every case 
but one, I was able to do what I needed in Pythoncard, and they covered 
a fair range of things
 - file manipulation / synching
 - games
 - email analysis
 - web scraping and presentation
 - photo management
 - FIM  
that's a Family Information Manager - like a PIM, but the focus is on 
shared data, so it does peer-to-peer cross-network synching for a shared 
calendar and address book.
 - toys   (e.g. the "flock" Pythoncard sample I think of as a toy - not 
quite a game, but no practical use :-)

In some cases, the finished application might have been nicer or more 
powerful without some constraint from Pythoncard - but then, they could 
all be improved in many different ways.

(I should say that I have used sizers in a number of them, which 
strictly speaking is "beyond Pythoncard". But even then I find it so 
much easier to think about and develop in a visual layout environment, 
and then when I'm 90% done, add the sizer code. In some cases, I've done 
that 90% and then decided it was easier and better to write geometry 
management code specific for the project than to force-fit it into sizers).

So, for me, the gain in ease-of-use and development speed has been 
substantial and significant, and I don't think I'm giving up much, if 
anything, by designing projects with PythonCard in mind - knowing I can 
"reach through" to wxPython direct for the small percentage of the code 
that needs to do so, in a small percentage of projects.

If you're developing substantial commercial apps, your mileage will vary 
- and you're probably outside the target audience of Pythoncard.


-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.4.1 - Release Date: 02/06/2005