[Pythoncard-users] FW: reply to Jon Udell

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

I often exchange email with people outside the list regarding PythonCard.
I've found lately that I often end up explaining my viewpoints about what
PythonCard could or should be and how to use it effectively. Sometimes this
duplicates a discussion that we already had on the list, but usually not.
Anyway, I'm going to start forwarding these emails either verbatim or with
minor edits. The first one is below.

Feel free to launch a discussion on any point that you disagree with or want
more explanation about.

ka

-----Original Message-----
From: Kevin Altis [mailto:al...@se...]
Sent: Sunday, September 09, 2001 9:48 AM
To: Jon Udell
Subject: RE: did you ever get a chance to look at PythonCard?


> > Hi Jon,
> > I never got a reply from you re: PythonCard, so I wasn't sure
> if you ever
> > got a chance to look at the latest version or not.
>
> Yes, I tried it a few days ago. I never really thought of HyperCard as
> an app framework, distinct from its interactive GUI-builder. That's what
> this is, currently, right? Interesting.

Building the app framework is the first step. If it isn't possible to build
simple apps using just an editor then things won't be much better in the
environment. The syntax and API and event model have to be easier to grasp
than say tkinter and wxPython. Even when we start providing a full
environment I want to support editing in Emacs or another text editor to
make the Unix folks happy, if nothing else. We'll probably be doing runtime
editing experiments in the next month.

> Does it make sense to imagine formally decoupling the GUI builder from
> the framework, I wonder? So that other GUI-builder projects targeting
> wxPython (or indeed other Python or non-Python open-source GUI kits)
> could work with PythonCard (and other frameworks)?

We're sitting on wxPython right now, but based on the work of the anygui
project http://anygui.sourceforge.net/ it might be possible to work on a
variety of GUI toolkits in the future. We probably won't know until they get
to at least release 0.3.

The main reason in my mind to force the use of the environment is that right
now it is too easy for the scripts and resource description names (ids) to
get out of sync (on_btn1_mouseClick handler goes with component 'btn1').
Once we are doing transparent data storage saves that problem will escalate.
That means anyone working say from Emacs will have to be responsible for
keeping their names in sync, but I think we'll provide some tools for
helping with this problem.

As you can see, we have a lot to do before PythonCard is directly comparable
to HyperCard and it is likely we'll continue to provide pieces of the puzzle
as samples or runtime elements like the Message Watcher, Property Editor,
and Shell before we get to the complete environment stage.

Since there is no compile, link cycle, you can open up the resourceEditor
sample to edit your layout description and keep your Python script open in
IDLE, PythonWin, Notepad, etc., make changes, save and then run your app
with a changed layout and/or script without closing the resourceEditor or
script editor. This is a little closer to SuperCard than HyperCard, but it
is pretty effective.

Does that make sense?

ka