pythoncard-users

[Pythoncard-users] Possible Project Idea

[Patrick K. O'B. <po...@or...>]

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.

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?

* Some kind of visual screen builder.

* Some kind of persistent data storage.

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.

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.

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.

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.

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

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

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

5. Repeat for the next app until PythonCard is perfect.

How does this idea grab everyone else? Good, bad, indifferent?

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

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

RE: [Pythoncard-users] Possible Project Idea

[Kevin A. <al...@se...>]

> From: Patrick K. O'Brien
>
> * Some kind of persistent data storage.

A lot of apps don't need persistent storage. We should probably also make a
distinction between the meta-data for widgets and the field/record data they
contain.

> 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.

That's part of the problem. HyperCard was a general purpose software
construction kit that was used for all sorts of applications. Even things
that couldn't be done well in it directly such as traditional BIG apps: Word
processor, spreadsheet, SQL database, draw program, etc. people using
HyperCard as a front-end if you will for BIG apps or used external code to
do do stuff that HyperCard didn't have built-in support for such as a grid
control (spreadsheet).

However, HyperCard did impose enough limitations through its model and tools
that for a lot of things it simply got in the way. I think this is what
Rowland refers to when he says we should just abandon the HyperCard baggage.
I'm pretty much convinced now that we should have a more generic model and
then if we want to follow the HyperCard model later, it should be built on
the more generic model.

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

Initially, I would suggest an abstraction layer between the storage of data
and meta-data and then use a backend that is easy to parse and manipulate
with tools outside of PythonCard. That means not using ZODB or any binary
storage format. The reason for the restriction is that until the model and
interfaces settle down we'll have to muck about in the resource and data
files, finding bugs, coding examples from scratch, etc.

> 3. Develop the app in a collaborative fashion to get feedback
> from more than
> one person.
>
> 4. Document as much as possible so that this serves as a tutorial
> of sorts.
>
> 5. Repeat for the next app until PythonCard is perfect.
>
> How does this idea grab everyone else? Good, bad, indifferent?

If there is one app that will cover most of the issues you've brought up it
is probably a contact manager like the addresses sample, but with more
features. However, in order to generate more interest an app that
manipulated and published web pages via a template system, outlines,
whatever, would probably be a better choice. What did you have in mind?

ka

RE: [Pythoncard-users] Possible Project Idea

[Patrick K. O'B. <po...@or...>]

What did I have in mind? Well, you kind of killed what I had in mind. <wink>

I was trying to find a reason to get more involved in PythonCard by finding
a project that overlapped my current interests. Namely, using ZODB as the
persistent storage for simple database applications that will have a
wxPython interface (as well as a web interface and possibly a Zope
interface). I also thought picking a sample app that embraced the need for
multiple windows (which a few people mentioned as a high priority) would
help focus our efforts.

Based on your feedback it sounds to me like there is no overlap. Sigh.

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

-----Original Message-----
From: pyt...@li...
[mailto:pyt...@li...]On Behalf Of Kevin
Altis
Sent: Monday, October 22, 2001 12:37 PM
To: Pythoncard
Subject: RE: [Pythoncard-users] Possible Project Idea

> From: Patrick K. O'Brien
>
> * Some kind of persistent data storage.

A lot of apps don't need persistent storage. We should probably also make a
distinction between the meta-data for widgets and the field/record data they
contain.

> 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.

That's part of the problem. HyperCard was a general purpose software
construction kit that was used for all sorts of applications. Even things
that couldn't be done well in it directly such as traditional BIG apps: Word
processor, spreadsheet, SQL database, draw program, etc. people using
HyperCard as a front-end if you will for BIG apps or used external code to
do do stuff that HyperCard didn't have built-in support for such as a grid
control (spreadsheet).

However, HyperCard did impose enough limitations through its model and tools
that for a lot of things it simply got in the way. I think this is what
Rowland refers to when he says we should just abandon the HyperCard baggage.
I'm pretty much convinced now that we should have a more generic model and
then if we want to follow the HyperCard model later, it should be built on
the more generic model.

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

Initially, I would suggest an abstraction layer between the storage of data
and meta-data and then use a backend that is easy to parse and manipulate
with tools outside of PythonCard. That means not using ZODB or any binary
storage format. The reason for the restriction is that until the model and
interfaces settle down we'll have to muck about in the resource and data
files, finding bugs, coding examples from scratch, etc.

> 3. Develop the app in a collaborative fashion to get feedback
> from more than
> one person.
>
> 4. Document as much as possible so that this serves as a tutorial
> of sorts.
>
> 5. Repeat for the next app until PythonCard is perfect.
>
> How does this idea grab everyone else? Good, bad, indifferent?

If there is one app that will cover most of the issues you've brought up it
is probably a contact manager like the addresses sample, but with more
features. However, in order to generate more interest an app that
manipulated and published web pages via a template system, outlines,
whatever, would probably be a better choice. What did you have in mind?

ka


_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythoncard-users

RE: [Pythoncard-users] Possible Project Idea

[Kevin A. <al...@se...>]

> From: Patrick K. O'Brien
>
> I was trying to find a reason to get more involved in PythonCard
> by finding
> a project that overlapped my current interests. Namely, using ZODB as the
> persistent storage for simple database applications that will have a
> wxPython interface (as well as a web interface and possibly a Zope
> interface). I also thought picking a sample app that embraced the need for
> multiple windows (which a few people mentioned as a high priority) would
> help focus our efforts.

We do need multiple windows. In fact, in order to make reasonable progress
on an environment we need to be able to create the environment in PythonCard
itself, since it takes too much time and effort to do every piece using raw
wxPython. If we can redo the Message Watcher, Property Editor (a better one
this time) as PythonCard windows they will be much easier to maintain and
enhance. My first window was the FindDialog and once we get past these
future direction messages, I'll get back to that. We can then start adding
other dialogs and windows we would need for an environment, redo the
resourceEditor, etc.

> Based on your feedback it sounds to me like there is no overlap. Sigh.

I wouldn't say that. Why can't that just be a sample? You'll probably have
less issues with a moving class spec which is what is going to cause trouble
with ZODB, which has no generic external tools for manipulating the
database. This is more or less the direction I wanted to go with the
textIndexer and addresses samples, both or which have the beginnings of a
more generic storage model.

So, your idea is a good one, why not get started? As pieces are solidified,
we can transition them to the general framework.

ka

Re: [Pythoncard-users] Possible Project Idea

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

Kevin Altis wrote:

>>From: Patrick K. O'Brien
>>
>>I was trying to find a reason to get more involved in PythonCard
>>by finding
>>a project that overlapped my current interests. Namely, using ZODB as the
>>persistent storage for simple database applications that will have a
>>wxPython interface (as well as a web interface and possibly a Zope
>>interface). I also thought picking a sample app that embraced the need for
>>multiple windows (which a few people mentioned as a high priority) would
>>help focus our efforts.
>>
> 
> We do need multiple windows. In fact, in order to make reasonable progress
> on an environment we need to be able to create the environment in PythonCard
> itself, since it takes too much time and effort to do every piece using raw
> wxPython. If we can redo the Message Watcher, Property Editor (a better one
> this time) as PythonCard windows they will be much easier to maintain and
> enhance. My first window was the FindDialog and once we get past these
> future direction messages, I'll get back to that. We can then start adding
> other dialogs and windows we would need for an environment, redo the
> resourceEditor, etc.


I have multiple windows working in the prototype of the design I posted 
to the list the other day.  I'm copying pasting code from 
PythonCardPrototype in to my prototype and have a sample app that:

Loads from a Resource file.
Has multiple windows, as specified in the resource file.
Can handle MouseClickEvent generated from Button
All Components ( Button ) in this case, can have their own Script object 
that handles any Events for the Component.

The Script/Scriptable model is very flexible and will allow us to build 
a user scripting environment ala Handlers and the last PythonCardPrototype.

Rewriting the MessageWatcher, etc. using strictly PythonCard should be 
pretty straightforward with Components and Scripts.

I'm making lot's of progress today and will post what I have this evening.


> 
>>Based on your feedback it sounds to me like there is no overlap. Sigh.
>>
> 
> I wouldn't say that. Why can't that just be a sample? You'll probably have
> less issues with a moving class spec which is what is going to cause trouble
> with ZODB, which has no generic external tools for manipulating the
> database. This is more or less the direction I wanted to go with the
> textIndexer and addresses samples, both or which have the beginnings of a
> more generic storage model.
> 
> So, your idea is a good one, why not get started? As pieces are solidified,
> we can transition them to the general framework.


If we can define a set of interfaces that provide an abstraction layer 
to discovering changes and then storing those changes, anyone could work 
on implementations for Zope, XML files, etc. on their own and then we 
could roll them into the code base.

Here are my ideas for a storage abstraction:

class ChangeEvent( Event ) :

    def __init__( self, changeable )
       self.changeable = changeable

class ChangeEventListener :

     def changed( changeEvent ) :
        raise 'abstract-method-error'

class Changeable :

     def addListener( changeListener )
         ...

     def fireChangeEvent( changeable )
         # call changed( ChangeEvent( changeable ) ) on
         # all listeners

Components can be Changable, and the persistence subsystem can register 
as a listener to a Document object

class Component( Changeable ) :
     ...

class Document( Changeable ) :
     ...

class DocumentStorage( ChangeEventListener ) :

     def changed( changeEvent )
         ...
 
Documents listen for ChangedEvents generated by Components, 
DocumentStorage objects listen for ChangeEvents generated by Documents.

Something like DocumentStorage would be the abstraction layer between 
PythonCard and Zope, mySql, XML files, etc.

When we get to the HyperCard model, we chould have a StackStorage class, 
or something to that effect.


> ka
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> 
> 



-- 
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