[Pythoncard-users] fwd: Where is the hypercard GUI interface?

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

There was a Feature Request tracker item in my inbox this morning that I
thought would be worth sharing with the whole list. This is another one of
those "what is PythonCard?" kind of threads, so you can add your two cents.
I don't think Andy (Andy is not Andy Todd) is on the mailing list, so he
probably won't follow-up.

ka
---

Isn't the point of a "hypercard" to provide an easy to
use GUI environment where you can drop down components
and double click on them and enter code?

And the metaphor of the GUI needs to be a cool RAD
framework e.g. cards on background, messages
travelling up through objects till a scrpit to handle
it is encountered.

I don't see any of this technology in this project -
or is all that coming?

P.S. If you want to see a fast GUI that gets results,
check out http://www.mediachance.com
Imagine that framework with python as the language!!

-Andy

and my reply...

Date: 2001-11-15 11:25
Sender: kasplat

Just for clarification. PythonCard is not HyperCard. As
stated on the mail lists many times, the first goal is to
produce a framework and then work on an environment at a
later date. Some of the samples (resourceEditor) and
runtime tools (Message Watcher, Property Editor, Shell)
show pieces of what we could have in the environment, but
are not an environment.

It is unclear at this point whether we will try and follow
the same message hierarchy as HyperCard. Currently, all
samples are effectively single card (implied), single
background stacks that manage their own persistance, but
there is a message path from widget to background to stack,
so a background handler (see tictactoe) is possible today.

It is also unclear whether we will keep with the idea of
editing a script per button/field/card/background/stack. I
would say that it is unlikely, since the plan is to allow
people to easily edit programs just using a plain editor as
well as use an environment editor.

PythonCard is less than five months old and while the name
is catchy, it has become clear that it carries a lot of
baggage and creates expectations that may never be met. The
big issue right now is whether PythonCard continues to hide
most of the details of wxPython. PythonCard at this point
is just a simpler way of using wxPython for simple cross-
platform apps with native widgets (tkinter for example
doesn't use native widgets). The amount of feedback and
developer help will determine the future direction of the
project and you should refer to past messages on the state
of the framework... for more info.

In the end, PythonCard is using HyperCard for inspiration,
not trying to duplicate it for Python.

Thanks,

ka