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

[Rowland S. <ro...@we...>]

As Kevin indicated, I haven't been able to participate in the actual 
development of PythonCard since our code-fest way back in July.  I'm 
very intrigued with the concept of building an extremly high level 
programming environment with a set of seamlessly integrated visual 
development tools.

I liked HyperCard back in the day, at least up to a point.  It was very 
easy to build simple to somewhat complex apps with HC.  But I really 
believe that HC dropped the ball in re providing a truly OO programming 
environment ( you couldn't define classes with attributes and methods ) 
and also in not providing a component object model that allowed HC to be 
extensible with both visual and non-visual components.  I'm no component 
expert, but for me that's definitely one of the requirements of an 
application development environment like PythonCard.

Personally, I think the idea of saying we want to build something that 
is all that HyperCard was and more was too ambitious.  Stepping back, 
maybe we should be saying something like:  Let's build a framework that 
is powerful and flexible, yet doable by a small number of people, that 
we can then build upon to produce even more powerful and flexible apps 
like HyperCard, or a skinnable app builder, or an IDE, etc.

My feeling is that the way to proceed is to step back and define less 
ambitious but more focused requirements, with an eye toward the future. 
  Since this is an object-oriented software project, we're going to have 
to take those requirements and build a robust object model.  The model 
needs to be very well defined before we even write a line of code to 
implement it.  We know we can build whatever we can design - the 
protoytpe is proof of that.  The next phase needs to be about stating 
exactly what we want to do, and then using the requirements to define 
very independent subsystems.

So, what would I want in an application development environment?

1. A well defined component model that allows for flexible extension of 
the overall framework.

2.  A high-level, well defined gui component model that can be 
implemented using one or more underlying gui toolkits - wxPython, GTK, 
Aqua, etc.  The gui wrappers take a lot of time, but they make us think 
about how we really want to interact with gui components and give us the 
freedom to expose those behaviors and attributes that we feel are 
valuable in our own way.

3.  A component communication model.  The prototype uses events to 
communicate between components ( Widget objects ) and user scripts.  But 
we really don't have a way for components to communicate with components 
- I'm not sure how to do that, but it seems important.

4.  A flexible scripting framework that allows us to plug in different 
scripting models for different classes of application.  We currently use 
a scripting model similar to VB ala method naming conventions.  It's 
possible we could have multiple scripting models - one could be more 
Model-view-controller based.  One could be based on action objects, etc.

Oh yea, and Multiple Windows ( seriously ).

Andy Todd wrote:

> 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



-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
    quoted in the book
    A Word a Day