Re: [Pythoncard-users] Possible Project Idea

[Andy T. <an...@ha...>]

Patrick,

I'm with you, let's get started.

Patrick K. O'Brien wrote:

> Here is an idea that might help us focus and determine the direction for
> further PythonCard development. The key to the idea is to start with the end
> in mind. By that I mean, let's start with a description of what we want to
> end up with and work backwards to see what we have to accomplish to achieve
> that end.


Making sure we make available working versions as often as possible. 
Working code is good code, big ideas are only useful if you are writing 
a book. As a project manager of mine once said "release hard and release 
often".

> 
> As I see it, the end that most people seem to want is a tool that lets them
> easily create simple GUI applications that manage information without having
> to know much about GUIs or databases or even programming. What does this
> imply?


I agree, its always been one of the goals of the project. Whilst no one 
has talked about it to the best of my knowledge (although I haven't got 
the archives handy), there implication was always that we would build 
the framework and then tack a build environment on top. Now you mention 
it, and I think about it, why shouldn't we build them in parallel.

> 
> * Some kind of visual screen builder.


We already have a head start here with the resource editor, property 
editor, message watcher and PyCrust. There is no reason why we can't 
build on these and produce a fully featured IDE. The missing link as I 
see it is a script editor that allows us to specify trigger code or 
methods against particular events, widgets or event/widget combinations. 
  Kevin may have some thoughts about using specific wx controls after 
his experimentation with the textEditor sample last week.


> 
> * Some kind of persistent data storage.
> 


My thoughts on this subject apply to PythonCard as a whole. We should 
use a simple, lightweight, storage layer that is easy to provide with 
PythonCard (or comes as standard with Python) but we should use a 
generic interface so that we can easily replace our storage layer. I 
know you are concentrating on Zope, and I'm leaning towards Gadfly at 
the moment. It needs a little light polishing and the author is being a 
little quiet at the moment, but I am holding out hope. We can simplify 
the interface even more with something like SQLDict 
(http://dustman/net/andy/python/SQLDict) to provide dot notation access 
to the data and Bob's your Uncle.

> This also implies that some things are less important. For example, support
> for multiple GUI toolkits would be nice, but users would be happy with just
> wxPython as long as it was made easy. Storing widget definitions in a
> resource file is nice, but users would rather not even see that, let alone
> care about how the resource file is formatted or whether it is XML or not.


I like resource files and agree with Kevin that we should keep them. We 
definitely need to wrap this up in any IDE we develop for PythonCard so 
that is step 2 on our requirements list.

> 
> With this in mind, I think we need to keep ourselves focused on the goal,
> and not get too sidetracked by things like the format of the resource file.
> Especially since we have no easy persistent data storage mechanisms that
> allow an app to have multiple windows/screens/records, and we have only the
> beginning of a visual screen builder.


See above, but perhaps one way to test out different storage layers 
would be to write a two-way interface between our databases and our 
resource files. We need a general data model to provide the basis for 
our work, but I for one would not like to dive straight into some kind 
of dynamic data access handling (for user defined applications).

> 
> So if the goal is simple visual construction of screens that access
> transparently persistent data, I'd like to suggest that we embark on a joint
> effort to create such an application from scratch, using the tools that we
> have so far in PythonCard, as a way to flesh out further requirements. The
> development of this sample application could even be documented as a
> tutorial for others.


It may be a little tricky to use as a tutorial, but you never know. The 
best part of such a project would be the development of an even more 
useful sample application and as a spark for the further development of 
the framework.

> 
> If there is interest in this idea, here is what I think needs to happen:
> 
> 1. Decide on a sample application that reflects the kind of app people would
> have done in HyperCard.


I think you've got it defined at the top of the page. I've been reading 
Joel on Software (http://www.joelonsoftware.com/) recently so I'll even 
start a functional specification tomorrow. Draft, obviously.

> 
> 2. Decide how we are going to store the data - CSV, ZODB, XML, MySQL, etc.


Lets start with ZODB and I'll try and then fit it to Gadfly or MySQL 
using SQLDict. If anyone wants to use XML they can try it later but I 
would suggest that is an output format rather than a storage mechanism.

> 
> 3. Develop the app in a collaborative fashion to get feedback from more than
> one person.


Always happy to chip in.

> 
> 4. Document as much as possible so that this serves as a tutorial of sorts.


And provide plenty of doc strings so that we can auto generate as much 
as possible. Rowland has sent me a copy of his code to parse spec.py and 
  generate documentation so there is no reason why we can't expand that 
to  document the framework and/or our developer application as well. 
With studious tweaking (and the borrowing of ideas from some of the 
other documentation projects) we can minimise our documentation as much 
as possible.

> 
> 5. Repeat for the next app until PythonCard is perfect.
> 
> How does this idea grab everyone else? Good, bad, indifferent?
> 


I like it, let development commence.

> ---
> Patrick K. O'Brien
> Orbtech
> "I am, therefore I think."
> 


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