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. Oncewe 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 (onethat 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 Morphicin 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.