Re: [Pythoncard-users] the future direction of PythonCard

Kevin,

A stimulating post, my thoughts and suggestions are interspersed below 
but, in summary, I'm not giving up and I would hope the other 
subscribers to this list can spare enough time and/or brain cells to 
keep this project going. I think we have built something pretty great 
and would like to keep it going.

Kevin Altis wrote:

> We're approaching the four month mark since the start of the PythonCard
> mailing list. This seems like a good time to evaluate where the project
> currently stands, whether we're on track, and what direction we should head
> in the future. Even the lurkers out there should respond in some fashion to
> this message if they're interested in the future direction of PythonCard.
> 
> Issues in no particular order:
> 
> Is anyone using the current prototype? We've had a reasonable number of
> downloads, but the list is very quiet. The apps I know about are the samples
> included with each release, some experiments of my own and Simon's blogger
> app. I'm probably forgetting something. Ron posted some source to the list
> and I'm assuming he is still experimenting with PythonCard. Is anyone else
> playing with PythonCard?


I'm using it. I'm trying to test and stress it but am very happy to 
report that I haven't found any problems yet. Maybe I'm not looking in 
the right places, or maybe I'm just lucky. Whatever the reason I shall 
keep trying.

> 
> Based on the current samples, is the current framework too complex or too
> limiting or just right?


It is a little complex to understand at first but once it all slots 
together I think we have a great operating model. My initial problems 
are probably due to my inexperience and no doubt some documentation 
would help. See my to do list at the end of this message.

> 
> What elements need to be added to the current framework before you would use

> PythonCard for your own work?


1. Multiple windows
2. Multiple windows
3. Multiple windows
4. Timers
5. There is no item number 5
6. Multiple windows

> 
> Is the most important thing having an environment like HyperCard?


I would say it is multiple windows ;-)

> 
> Project Roles
> The last update to the roles list was on July 12th, so it is out-of-date
> http://aspn.activestate.com/ASPN/Mail/Message/676720
> At this point, I'm doing most of the work on the framework and samples.
> Patrick is working on PyCrust, which we use for our shell and namespace
> viewer. Andy is still active, but not on the framework. Both Neil and Robin
> answer questions, but otherwise are not currently involved in PythonCard
> code. Rowland is not active either, though we owe a debt to him for the
> original framework, ideas, etc. Rowland and I mostly chat about PythonCard
> outside the list. Roman helped start the distutils work, but Andy took that
> over. There have been a few people offering to get involved, but real life,
> work, etc. has overridden most of the good intentions. There is a limited
> amount we can accomplish without more developers. This will have an impact
> on the scope of the project, so if you're interested in a particular area
> please speak up.
> 
> Documentation
> Suggestions for getting some docs done? Anything in particular you want in
> terms of documentation?


A users guide would be good I think, also a reference guide. I have 
started on the first steps towards a reference guide. Specifically I'm 
trying to generate the widget types and their valid attributes from 
spec.py into some form of HTML (first, then XML perhaps) but it isn't 
ready for public consumption yet.

I'm really interested in generating large parts of documentation 
automatically but I'm not a huge fan of the complex solutions they are 
talking about over on the Doc-Sig (http://www.python.org/sigs/doc-sig), yet.

> 
> The project name
> Is everyone happy with the name PythonCard? I wouldn't bring this up except
> that recently I learned a number of people had never even bothered to look
> at PythonCard because of the implied similarity to HyperCard. There are a
> lot of people out there that have never used a Mac and even if they have, a
> lot of people never liked HyperCard and considered it a toy for building
> apps. On the other hand, a lot of HyperCard users expect PythonCard to
> provide a complete environment, so the name doesn't reflect so much what we
> have today, but what we hope to achieve. It doesn't help that wxPython
> doesn't run on the Mac yet.


I'm happy with the name. As for the link with HyperCard turning people 
off, we do say on the project web page (http://pythoncard.sf.net) "This 
is a project to build a HyperCard like tool in, and using, the Python 
language"

Maybe we could stress it more but the second sentence on our home page 
should be enough shouldn't it? My only suggestion would be to emphasise 
as often as possible that HyperCard is an inspiration, not a specification.

Failing that, I believe the name 'Monty' was suggested back when this 
list was on Yahoo! and checking on sourceforge that project name isn't 
taken yet ;-)

> 
> Should we move beyond the prototype and make the next major release an alpha
> version of the real framework?


That depends on what we decide the alpha release should include. I know 
thats a circular argument but what I think we need to do before anything 
else is state what we are trying to achieve. I know Kevin has an idea, 
as do I, of what we want from PythonCard (see below) and so probably 
does everyone else reading this list. What we haven't done recently is 
check whether we are all on the same page. Lack of posts to this list 
don't help of course, so shout out please everyone.

> 
> How thin should the framework layer be over wxPython? That's a loaded
> question. The implication is that we will only be able to achieve our goals
> with wxPython instead of alternative GUI toolkits for Python. That may or
> may not be true. What do we want to achieve with our framework sitting on
> top of wxPython that wxPython doesn't provide?


Simplicity. I looked briefly at wxPython (and tkinter, etc.) when I 
started to learn Python and ran away - very quickly. Necessarily these 
toolkits are very close to the os/hardware, which is great if you are 
writing Word or Mozilla but not if you are writing an order entry 
application (like I want to do).

The decision to use wxPython was a pragmatic (and I think correct) one 
when we started out on the prototype and still holds true for me. Once 
we have a working framework with a consistent API we could look at the 
applicability of different backends but let us build the horse first 
before selecting a different cart.

> 
> What parts of the framework are most important to you? Some possibilities:
>   Layout descriptions in resource files
>   Automatic widget creation and event binding
>   Dot notation for widgets and other framework items
>   on_widget_event style handlers
>   runtime tools such as the shell, message watcher, property editor


In order; resource files, runtime tools, dot notation, modular 
architecture. Oh, and multiple windows.

> 
> Are the samples useful?


They are, but then I would say that wouldn't I.

> 
> What do you want PythonCard to be?


I want to be able to easily build small to medium sized GUI applications 
  with as little (or as much as necessary) coding as possible. I only 
briefly used HyperCard but I've also used VB, Delphi, Oracle Forms, 
Powerbuilder, etc. and an easy to use version of those kind of app 
builders is what I am after. I'm mindful of the other tools under 
development as well though (specifically Boa and wxDesigner) and suggest 
we try and complement them rather than compete.

I am also a fan of CP4E and think that PythonCard could address this 
requirement as well. Is it in line with my first requirement? Possibly, 
if you consider the shell and the resource editor. Ease of use should be 
our aim, 'kiss' (keep it simple stupid) our motto.

> 
> I definitely pushed PythonCard in the direction I thought it should go back
> in July and I'm going to continue to pursue PythonCard in some form, but it
> may be time to revise some of the original goals. I'll give other people a
> chance to respond before stating some of my own preferences.


I hope I've added some fuel to the fire. I'd like to take this 
opportunity to thank Kevin, Patrick, Rowland, Neil, Robin, Roman (and 
anyone else I've forgotten) who have built something pretty wonderful in 
a few short months. I for one am not giving up on it. Even if we stopped 
work on the framework tomorrow we still have a valuable body of code to 
work with and on. As I've said to Kevin privately I don't feel qualified 
to play with the framework code but one of my aims whilst participating 
in this project is to acquire the knowledge to be able to do so. It 
would be easier if the folks who wrote the code are around to help me 
understand it though ;-)

> 
> This is an open-ended post, so feel free to bring up any topic you think
> relates to the current state of PythonCard or its future even if I didn't
> touch on the topic above.
> 
> ka
> ---
> Kevin Altis
> al...@se...
> 

As I promised at the top of this mail, here are the tasks I'm currently 
working on (or thinking about);


Documentation. I'm trying to write some routines to automatically 
generate components of a reference guide. I think we also need to revise 
  and expand the getting started guide that Kevin wrote and perhaps add 
a guide to how the framework is structured for people who wish to 
examine it (like me).

Data store support. I'm trying to add support for CSV files and more 
varieties of relational databases (Gadfly, PostrgeSQL, Oracle) to the 
dbBrowser sample. My next step would be to try and fit one of these 
(probably Gadfly) into some kind of persistent storage layer for the 
framework as a whole. This slightly overlaps Patrick's investigations 
with ZODB but I think they don't overlap. I got a bit side tracked here 
as Gadfly doesn't operate 'out of the box' with Python 2.0+ and have 
started a thread on the DB-SIG mailing list about upgrading it. That has 
distracted me a bit but should benefit the wider Python community as 
well as, eventually, PythonCard.

Improve the dbBrowser application. My target is to produce a useful 
general purpose RDMBS tool like TOAD (http://www.quest.com/toad). That's 
probably a little ambitous but I am shooting high. If I continue this 
application I may have to move it to wxPython but PythonCard is giving 
me a valuable head start. If I didn't have PythonCard I wouldn't have 
started on this path, reason enough for me to be thankful for PythonCard.

Statement of requirements. We need one. If we know what we want, we know 
how far we have to go to get there. We started with a broad idea of 
which widgets and events we wanted to support when the prototype kicked 
off but now is a good time to more properly define our requirements. 
I've put my broad thoughts in this mail and am happy to discuss them 
with you all.

Packaging. We have used distutils to create the packages which can be 
downloaded from SourceForge. Most of the good work was Roman's, most of 
the head scratching was mine. The documentation for distutils is bad, it 
  provides a very limited example but never explains how it works or 
what its limitations are. I think we need to dig a little deeper into 
the structure of the standard utilities to make them more usable for 
PythonCard (subclassing is apparently the way to go but I haven't tried 
that yet). I also think some new documentation is required and I've 
started on that too. The activity level on the distutils-sig mail list 
makes this one look quite lively so I don't think we will step on any 
toes if we start to produce some more understandable documentation for a 
part of the standard library ;-)

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Another year older, still no wiser." - Me, on my birthday