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

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

> From: Dan Shafer
>
> I'm inclined to agree with the other old 'Card fart here (back at ya,
> Danny!) when he says that HyperCard probably carries around a tad too
> much baggage to be useful in this situation. And Kevin's point that
> an app built on top of PythonCard (or whatever we end up deciding to
> call it) that provides the lightweight data storage automation that
> HyperCard users know and love is probably a better direction anyway.

We (okay Rowland and I) have been carrying around a lot of design baggage
from HyperCard imposing arbitrary limitations of a stack/background/card
metaphor on the framework since July along with the notion of an actual
controlling PythonCard application like the HyperCard application was with
stack documents, even though we got rid of the loader many months ago. It is
much easier to free the framework now to be much more flexible and put the
HyperCard metaphor back on top of a more robust underlying design than to
try and squeeze many of these other ideas we have into an overly restrictive
model.

> I'm fine with calling these things we create applications rather than
> stacks. But the other terms for the components leave me cold and
> wondering if I'm working in Visual Basic again. (That's OK. It's a
> recurring nightmare.)

So, tell me about your childhood. Mr. VB beat you, didn't he? Yes, that's
it, share your feelings. ;-)

But seriously, we should be explicit about what is bad about VB. Being able
to put components together is good. Simple layout is good. We just need to
leave out the icky parts of VB and the same goes for HyperCard...

> So after spending some time noodling about this, here's a concrete
> proposal that we can at least start shooting at.
>
> A Monty application's visible interface consists of one or more
> Master Layouts which define sets of components that are common to all
> Windows that share a given Master Layout. Windows optionally have
> additional components that are not defined in their Master Layout.
> One type of component is a Pane, which is a container for other
> components. It is legal to nest Panes. The simplest case is a Window
> which is identical to its Master Layout in every respect.
>
> Just a straw person. Let's beat it up!

I don't have a concrete opinion yet, I want more elaborate and complex
samples to help us decide what to use and what to drop and what to name
things. And I would like to see more people that want to shape this thing
throw their hats in the ring as well and slap some programs together and
then make their opinions known on what they like and don't like and what
they want and don't want. If you don't vent now, you can't legitimately
complain later.

We are at the fluid stage where the magic happens.

ka