RE: [Pythoncard-users] What Do We Call These Things?

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

> From: Dan Shafer
>
> Kevin suggested that he was thinking of moving away from HyperCard's
> stack-background-card metaphor for a number of reasons. But he
> remains appropriately adamant about keeping the simple-is-good
> philosophy behind PythonCard. He ran up the flagpole the idea of
> using Application, Form, and Panel. What follows is my thinking on
> the subject, FWIW.
>
> Whether it's good, bad or indifferent for PythonCard to "lose" its
> "HyperCard-ness" is, I think, less important in the long run than the
> simple-is-good philosophy. But I think there's something
> fundamentally sound and intuitive about the stack-background-card
> metaphor that shouldn't get lost, at least for the Inventive User
> audience. These non-programmers don't want to think in terms of
> applications, forms and panels. Those are "geeky" things.

The reasoning goes like this...
Application is pretty obvious. A script is really an application.
Applications are what everyone runs on their desktops. We even use the term
WebApp which is really a horrible name. I suppose you could use the term
"Program", but my gut tells me that if you say "Application" even newbie
programmers and creative users know what you're talking about. Since there
is no required runtime environment to use a PythonCard application, the
stack/document confusion can go away.

Form is 100% from my experience with Microsoft (MS) and wanting to leverage
the "education" they've already given 3 million plus VB coders. Visual Basic
programmers design Forms. .NET uses the terms WinForms for things outside
the browser and WebForms inside the browser. [As a side note, the current
implementation of WinForms and WebForms does not provide an easy way to
translate between the two, which I'm told is because MS is a large company
with two large programming groups that are not communicating very well :)]
Whether you like it or not you are going to here about Forms a lot as the MS
marketing kicks into high-gear this year.

In MS terms, a Form can have "decorators" like a menubar, statusbar, and
various window styles. That is what we are doing with Background in the
resource file. I would like something that is just the stuff inside the
Form. In wxPython, this can be a wxPanel and PythonCard is using a Panel,
but for the most part it is hidden from the user code. MS also uses Panels
inside Forms. You can nest Panels.

For PythonCard, there is not much difference between the GenericDialog
(modal dialogs) and Background classes except that GenericDialog is modal
and needs buttons with specific button ids for OK and Cancel. You should be
able to use the same layouts for either "window style".

The only real reason PythonCard doesn't do scrolling windows right now is I
couldn't decide where to split the panel/background/window settings. I did a
working scrolling window demo back in August which just contained a really
big Panel and it worked fine, but the window has a different window size
than the Panel and at the time we still had 'size' in the 'stack' and we
still don't distinguish between window and panel size. The same issue
applies to other window styles.

> I'm not certain that stack, card, background is the requisite
> terminology set, but I do feel that something _like_ that set of
> terms is necessary.

Another possibility is what I suggested back in October when I started to
get more serious about making PythonCard wxPython specific. PythonCard is a
simplified way of doing wxPython applications. A more direct clone of the
HyperCard stack/background/card metaphor could be used in an application
written in PythonCard and would provide the lightweight database persistence
expected of HyperCard apps. Even if/when we get the document classes in
shape to support automatic saving of data and metadata for components, it
will still be optional because not all applications need it.

In fact, this could be a commercial possibility for someone or some company
that wants to cater to ex-HyperCard users. Just an idea. I specifically want
to avoid the GPL so that this kind of thing is at least a possibility.

When PythonCard started I was definitely thinking in terms of stack,
background, and card. All PythonCard apps use a Single Document Interface
(SDI) style instead of Multiple Document Interface (MDI) and the resource
format reflects the further restriction that there is only one menubar,
which is more of a Mac thing, that Windows or Linux SDI where each "Window"
can have its own menubar.

As we progress the sweet spot I have in mind is somewhere between an
"inventive user" and a VB-programmer and I would like to cater to both.
PythonCard should be appropriate for someone learning Python as their first
programming language in addition to someone coming from HyperCard, HyperCard
clones, Visual Basic, REALBasic, and the tired masses of people like me that
beat our heads against Java trying to build GUIs and eventually gave up. I
don't particularly care about meeting the needs of teams of "sophisticated"
programmers that would be more happy with Delphi or Microsoft Visual Studio,
though hopefully PythonCard will be useful to those folks as well.

Obviously, this stuff is not entirely crystal in my mind and we have a lot
of room to morph the existing structure.

ka