Yep!
Cheers,
Alan
------
At 4:07 AM -0800 2/28/00, Jay Carlson wrote:
I think all this talk about Visual Basic stirs up unnecessary loathing. Lemme summarize and rephrase some of the messages I've made it through:
It Would Be Nice If Squeak had the same level of UI construction, extensibility, and friendliness to users at different sophistication levels, as HyperCard.
HyperCard has a collection of different control types, roughly mapped to what's in the Mac toolbox. You can build a UI that (more or less) looks like what users normally see on some platform. Just drag the components off the palette.
HyperCard explictly has multiple access levels. At the browsing level, I can just interact with an app without worrying about messing it up. At the scripting level, I can write code associated with everything I see. In between, there are some construction activities that don't require me to know as much about the internals of the system. (I think that any Squeak level system would have at least one level beyond what HC regards as "scripting"; there's more detail available in Squeak than in HC.)
HyperCard has Undo. That's important. No, you can't reverse arbitrary computations, but when you do something disasterous in Morphic it's often not clear what to do to get back. For example, I keep moving subpanes out of their containers, and they never seem to want to fit back properly.
My favorite is when you select the wrong level of morph to manipulate---like the text, rather than the scrolling view that surrounds it. The first time I did this, I said "wow! look at all the generality in the system!". The second time, it made me wonder "is there some way of automatically locking substructure that an app isn't dealing with?". The third time I just got annoyed. I'm still trying to get my head around Paragraph, so these kinds of changes in Morphic are beyond me for the moment.
I don't need to convince Squeak people that some aspects of a HyperCard-y model are the right thing. From what I can tell, Squeak *is* moving in this general direction. OK, maybe consensus on a requirements set could better congeal a roadmap on how to get there (and thus suck in more people to work on it, which would make me happier). But construction is at the core of the dynabook; I know we'll be working on it, even if a deployable-app capability doesn't fall out as soon as everyone would like.
Maybe that's a key difference between HC and VB. Both make it easy to build UIs, but VB is concerned, above all else, with being able to deploy apps.
Jay
squeak-dev@lists.squeakfoundation.org