[Fwd: Morphic Wrappers] (fwd)

Daniel Vainsencher danielv at netvision.net.il
Fri Oct 2 09:32:56 UTC 1998





Gerardo Richarte wrote:

> Daniel wrote:
>
> > Double click on my just dragged supposedly wrapped Form. Bummer -
> > Morphs aren't really wrappers. They don't give you a message menu,
> > they just blink dumbly.
>
>     I had this problem myself, and Leandro [Caniglie] also has it. Once
> we use MorphicWrappers, we want everything to act as a MW, but no...
> As a result of this we started moving some messages in MW to Morph, this
> work is not finished yet, but it will be soon. We have to solve some
> design problems... if we move doubleClick menu, drop menu or keyboard
> handling to Morph then no Morph will be able to use those events
> anymore.

Somehow the message handling needs to be integrated. I mean that Morphs
seems to have an "idea" about how to treat incoming events (what
mouse/keyboard combinations should produce what Menus/actions), though I
haven't deduced it yet. Could be just me, but I'm constantly surprised at
the system's reactions.

MWs have another idea entirely of what is done with events, which is rather
simple - double clicks and drops bring up the method categories/instance
variables list. A single click moves focus to the object. Text entry is done
in the context of the object that has focus.

It seems to me that it's time to make simple rules again, similar to those
that smalltalk had initially (one button to select, one button to edit info,
one button to edit views, and one ring to bind them all in darkness. Hmmm,
sorry about that.) that capture Morphs and MWs.

Maybe something like the normal rules, but with some sort of meta-addition.
Maybe there should be a way to cause the system to show you a menu of
context, ask you to choose who this should go to.
For example, shift select asks you whether you are selecting the string in
the edit box, or the edit box, or the browser in which it resides, or the
world around it.
Or something like that.

Maybe there should be three levels - the base (user level) info, the level
above it (the control) and a choice of all levels.
bind the level to key board combinations - the first is regular, nothing
pressed. The second requires Shift pressed, the third requires Alt.

Then give the three buttons specific and constant meanings, for example, the
first selects, the second brings up an app dependent menu (taken from the
borwser), and the third brings up a an object dependent menu (taken from the
string being browsed), including the message categories.

The matrix of combinations allows you all kinds of access to all kinds of
object on the screen, though I'm not completely sure it'd be simpler in
practice than the current scheme.
Maybe someone can come up with something simpler?

>
>
>
>     As an example of this, suppose you have a GraphMorphicWrapper (one
> that I've done, and will post it somewhere soon) and you drop something
> over it. It can be a Number, as argument to some message, or it can ve a
> Vertex, so it can be added to the Graph.

This is the problem I address above. It would done by dragging with the
third button to choose a method, and dragging with the first button to
simply drop it as info.
Though this requires that the decision of what to do fall on the target of
the drag, and I don't know if this is practical.

> (this can be a default
> message... it's not a bad idea). I solved this problem checking the
> class of what is dropped, but this is not a good generic solution... Now
> I'm thinking that a default message can be sent holding shift down while
> dropping something in the MorphicWrapper... I'll test this, it sounds
> good, what do you think?

I don't know if this one message would be enough.

> (still don't know how to solve keyboard focus)

I'm not sure what you mean by this.

> > I started thinking about it, and realized that wrappers allow Objects
> > to live in Morphic, imitating Morphs. But by adding all that wonderful
> > Wrapper functionality, you leave Morphs behind, and therefore, they
> > don't mix.
> >
> > I was wondering whether and how you intended to address this.
>
>     Ohhh, emmmm, well... one solution can be to turn everything Morphic
> in something MorphWrapped, and leave some Morphs as construction blocks,
> but I don't know if this is a good design idea.

If you have a FormWrapper, what would it allow you to do?
Just view? or also edit? how about special effects? seems you do need the
application to come in somewhere, which implies objects that aren't really
wrappers...

Might be better to put the functionality of allowing you to send messages
via dragging or shifting the focus into Morphs, always using the third
button.

> > Off the top of my head, it seems to me that the functionality in
> > Wrappers today might be better split between two levels, one allowing
> > a readable represetation on screen and the basic Morph menus, and the
> > next level providing the message sending interface.
>
> What do you mean with “message sending interface”? If you mean talking
> (typing) to an object, this can be moved to Morph with some work: We
> have to solve the problem of setting the keyboard focus by clicking on
> an object, because there are some morphs that need keyboard for their
> use (StringMorph for example)

By "message sending interface" I meant both typing and using the message
menu - that is, any way that the system allows the user to send arbitrary
messages to objects.
I view morph as having two great features or ideas.
A. The user sending messages.
B. All objects can be represented in Morphic, sometimes by being wrapped.

I view these two features as rather separate, and each needs a nice place to
live in, not nessecarily the same place 8-).

> > Which level is used should be decided by the World you're in.
>
>     Can you expand this, please?

Maybe we don't always want to be able to send message to objects. Sometimes
you just want to use the application. So define two kinds of worlds - one in
which morphs allow message sending, and one in which they don't. It's a
possiblity, but I think I'd always live in the user-message-sending (UMS)
world.

> > What do you have in mind for version 2?
> [snip]
>     + History (by Class) is implemented in CodeStringMorph.

Halleluja!!

> [neat additions and changes galore]

Cool.





More information about the Squeak-dev mailing list