Discussion:
[DISCUSSION] Hidden and Open: O'Keefe as "everyman"
(too old to reply)
Doug Clapp
2012-01-28 11:20:19 UTC
Permalink
Richard O'Keefe said, among other things...
If it had ever occurred to me to try shift-clicking on halo handles, I
might have discovered this ages ago.

Welcome to Squeak! A oxymoronic environment where things normally hidden --
source code, system innards, etc -- are naked and open to inspection or
change...

and...

where things normally obvious -- how to move a window, features specific to
the application/morph -- are hidden in pop-up menus or halos or
Shift-clicked halos.

How odd!

Fire up World menu/New Morph../Outliner/(oh you haven't figured out how to
make them all show in a sub-menu yet? Shame on you)
/EToyHierarchicalTextMorph to make an outliner morph.

Well, there it is! So...try and use it! I know, I know..there's no menu
bar with choices and no menu bar at the top of the project window. But
hey...the specific actions of this morph -- you know: how to add items to
the outliner, indent and so on -- are probably in the halo menu, right?

Let's see. Make the halo visible, look on the menu. Nope, not there.

Click madly for a bit. Wait! If I don't click on the text, and I don't
click on the triangle...I get a pop-up menu! It reads

-- expand all below me
-- addChild (pretty "smallTalky" heh? kewl...)
-- delete

Well, ok, I get it now. That wasn't hard, was it?

The moral? As above: Features most used and needed by "normal folk" wishing
to do things are hidden or awkward to find and use, while the system itself
is marvelously open and accessible.

Folks, it's 2003. If we can't have morphs with default menus, can we at
least have a menu bar now???

And can we nuke this 3-button mouse notion? Some people have "wheel" mice,
where the wheel can be clicked to serve as a 3rd button, but the whole "3
button" thing is odd, distateful, unneeded and a total anachronism. Put the
common halo commands (like I NEED to rotate my morph???) on a menu bar, make
the item highlighting intelligent (don't get me started on THAT one) and be
done with it!

Jeesh.

Doug
Alan Grimes
2012-01-28 11:20:19 UTC
Permalink
Post by Doug Clapp
where things normally obvious -- how to move a window, features
specific to the application/morph -- are hidden in pop-up menus or
halos or Shift-clicked halos.
THERE ARE SHIFT CLICKED HALOS?!?!??!?!?!?!?!
--
I WANT A DEC ALPHA!!! =)
21364: THE UNDISPUTED GOD OF ALL CPUS.
http://users.rcn.com/alangrimes/
[if rcn.com doesn't work, try erols.com ]
Brent Vukmer
2012-01-28 11:20:19 UTC
Permalink
alangrimes++ # hahahahahaha

-----Original Message-----
From: Alan Grimes [mailto:***@starpower.net]
Sent: Wednesday, February 12, 2003 3:17 PM
To: The general-purpose Squeak developers list
Subject: Re: [DISCUSSION] Hidden and Open: O'Keefe as "everyman"
Post by Doug Clapp
where things normally obvious -- how to move a window, features
specific to the application/morph -- are hidden in pop-up menus or
halos or Shift-clicked halos.
THERE ARE SHIFT CLICKED HALOS?!?!??!?!?!?!?!
--
I WANT A DEC ALPHA!!! =)
21364: THE UNDISPUTED GOD OF ALL CPUS.
http://users.rcn.com/alangrimes/
[if rcn.com doesn't work, try erols.com ]
Richard A. O'Keefe
2012-01-28 11:20:20 UTC
Permalink
Alan Grimes <***@starpower.net> wrote:
THERE ARE SHIFT CLICKED HALOS?!?!??!?!?!?!?!

Yep.

So far, I've found:

shift-click on Viewer brings up a Vocabulary instead;
shift-click on Debug brings up an Inspector instead of a menu;
shift-click on Eyedropper brings up an ObjectProperties sheet.

Other halo handles either ignore shift-click or do the same thing
they do with a plain click.

A Vocabulary seems to be some sort of browser. I'm not sure what
you would do with it, but I imagine that people who do like a quick
way to get one.

If you make a Tile from a Morph, what is it actually _good_ for,
other than Menu|Hand me this object?
Ned Konz
2012-01-28 11:20:20 UTC
Permalink
Post by Richard A. O'Keefe
If you make a Tile from a Morph, what is it actually _good_ for,
other than Menu|Hand me this object?
It can then be used as a noun in eToy scripts.
--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE
Bill Spight
2012-01-28 11:20:21 UTC
Permalink
Dear Ned,
Post by Ned Konz
Post by Richard A. O'Keefe
If you make a Tile from a Morph, what is it actually _good_ for,
other than Menu|Hand me this object?
It can then be used as a noun in eToy scripts.
It can? How? That's precisely what I tried to do yesterday, to no avail.
(Using drag-and-drop, which worked with other tiles.)
Post by Ned Konz
OK, let's open a viewer on the go game morph and get the tile
for the game history.
[An instance variable.]
Post by Ned Konz
No can do, right?
[Can't see any instance variables in the viewer.]
Post by Ned Konz
Well, maybe I can send a message to the go game. We can get its tile.
Let's add it to the script. Oops. No puedo,sennor.
Where did I go wrong?

Thanks,

Bill
Ned Konz
2012-01-28 11:20:21 UTC
Permalink
Post by Bill Spight
Dear Ned,
Post by Ned Konz
Post by Richard A. O'Keefe
If you make a Tile from a Morph, what is it actually _good_
for, other than Menu|Hand me this object?
It can then be used as a noun in eToy scripts.
It can? How? That's precisely what I tried to do yesterday, to no
avail. (Using drag-and-drop, which worked with other tiles.)
You have to have a sentence already; you can replace its noun
(receiver or object) with the tile. Just drag the tile over the old
noun to change it.

Open a viewer on some other object, and drag out the sentence
"SomeObject start script script1". Drop it on the desktop. Now get a
tile from another object; you can drop that tile on SomeObject and
change the receiver of the start script message.
--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE
Bill Spight
2012-01-28 11:20:21 UTC
Permalink
Dear Ned,
Post by Ned Konz
Post by Bill Spight
Post by Ned Konz
Post by Richard A. O'Keefe
If you make a Tile from a Morph, what is it actually _good_
for, other than Menu|Hand me this object?
It can then be used as a noun in eToy scripts.
It can? How? That's precisely what I tried to do yesterday, to no
avail. (Using drag-and-drop, which worked with other tiles.)
You have to have a sentence already; you can replace its noun
(receiver or object) with the tile. Just drag the tile over the old
noun to change it.
Open a viewer on some other object, and drag out the sentence
"SomeObject start script script1". Drop it on the desktop. Now get a
tile from another object; you can drop that tile on SomeObject and
change the receiver of the start script message.
That sounds like what I did. Just to make sure, I tried again. I made a
new RectangleMorph, opened a viewer on it, and dragged out the script.
Then I made a new GoMorph, opened a viewer on it, got its tile, and
dropped in on the script.

Maybe my problem yesterday was not dropping it on the Rectangle tile. I
dropped it right on there. Nothing happened to the script, except it had
the Go tile sitting on in. No matter where I dropped, no effect.

What's wrong?

Thanks,

Bill
Ned Konz
2012-01-28 11:20:24 UTC
Permalink
Post by Bill Spight
Dear Ned,
Post by Ned Konz
Post by Bill Spight
Post by Ned Konz
Post by Richard A. O'Keefe
If you make a Tile from a Morph, what is it actually _good_
for, other than Menu|Hand me this object?
It can then be used as a noun in eToy scripts.
It can? How? That's precisely what I tried to do yesterday, to
no avail. (Using drag-and-drop, which worked with other tiles.)
You have to have a sentence already; you can replace its noun
(receiver or object) with the tile. Just drag the tile over the
old noun to change it.
Open a viewer on some other object, and drag out the sentence
"SomeObject start script script1". Drop it on the desktop. Now
get a tile from another object; you can drop that tile on
SomeObject and change the receiver of the start script message.
That sounds like what I did. Just to make sure, I tried again. I
made a new RectangleMorph, opened a viewer on it, and dragged out
the script. Then I made a new GoMorph, opened a viewer on it, got
its tile, and dropped in on the script.
Maybe my problem yesterday was not dropping it on the Rectangle
tile. I dropped it right on there. Nothing happened to the script,
except it had the Go tile sitting on in. No matter where I dropped,
no effect.
What's wrong?
I don't understand the problem, unless there's a bug somewhere.

I just did this successfully:

* make a Rectangle and an Ellipse.
* open up the Rectangle's viewer.
* pull out the sentence "Rectangle's color <- {red patch}"
* drop the sentence on the desktop; it becomes a script.
* get a tile for the Ellipse.
* drop the Ellipse tile on the Rectangle's tile in the script
* run the script: the Ellipse turns red.
--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE
Bill Spight
2012-01-28 11:20:24 UTC
Permalink
Post by Bill Spight
That sounds like what I did. Just to make sure, I tried again. I made a
new RectangleMorph, opened a viewer on it, and dragged out the script.
Then I made a new GoMorph, opened a viewer on it, got its tile, and
dropped in on the script.
Maybe my problem yesterday was not dropping it on the Rectangle tile. I
dropped it right on there. Nothing happened to the script, except it had
the Go tile sitting on in. No matter where I dropped, no effect.
What's wrong?
After a couple of more emails from Ned Konz, I tried again. As he
suggested, an empty script (^ self) is not enough. This time I made the
script, 'Rectangle hide', then dropped the Go tile over the Rectangle
tile, and made the replacement. So far so good.

I am doing this because I want to send a message to the GoMorph that I
see no way to do with the tiles available. So I switch the script to
written form and replace 'hide' with 'board: ***@5'. I am telling the Go
morph to change the size of its board to 5 by 5. To my surpise (having
tried something like this before) the script is accepted. Now to run it.

Oops! Debug time. 'Message not understood'. The message, OC, is 'board:
***@5'. The object that does not understand it is Player51. Well, that's
not surprising. Why should it understand? And it's not too surprising,
but a bit dismaying, that all is not what it seems. Wheels within
wheels.

However, this whole excursion was in response to Andreas's notes
Post by Bill Spight
The point was usability and
efficiency.
Don't you realize that the Morphic that is perfect for
eToys *is* the one that is perfect for programmers?
To me, this is the logical result of many of the shortcomings of Smalltalk.
For example, subclassing for using the framework.
Given this, any attempt to "clean up" Morphic is doomed to fail if it does
not address the "usability issues" for the programmer. The best you can hope
for is a temporary effect but any newbie can (and therefore will!) write
code that breaks the framework. Some of this code will either be cool or
needed enough so that someone else is going to use it and you'll end up
exactly where we are right now.
Documentation, tests, etc. will (while being useful) not solve this problem.
Bridging this gap, making the "system
level" part of Squeak more like eToys is the thing that needs to be done. In
particular in the UI area since that's what most people will look at and
play with first, so it's the place where strong fences are most needed
(present in eToys).
I would love to work within the framework (whatever that is, exactly). I
like Morphic, it's why I'm here. :-)

But I need instance variables of types not among the 9 that are not
quite obviously available for scripting. I need more functionality (at
least, I think I do). I need better communication with Morphs than I
have seen. (It's probably available, but where?)

I'm a newbie, I made some Morphic subclasses, I broke the framework. So
sue me. Did I want to do that? No. Is Smalltalk the problem? Not for me.
Without it how could I have gone oven the fence to get done what needed
to be done? Is documentation or the lack thereof a problem? Not so much
for some people, but definitely for me.

I have a functioning GoBoardMorph (subclass), and a GoMorph (another
subclass) that is not fully functional yet, but it's getting there. Are
you cool with what I have done and am doing? Fine. No problem. If not,
and there seem to be those who are not, then help me out. I'm perfectly
willing to redo everything. Is that too much time and trouble? (It would
be for me.) OK, give me some good documentation. Is that too much time
and trouble? If so, what can I say?

Thanks for listening,

Bill
Alan Kay
2012-01-28 11:20:24 UTC
Permalink
Etoys were made specifically for children and specifically for a few
hundred projects that would be neat for them to do. Squeak is made
for experts and for pretty much every kind of project. The user
environment we didn't get done was the one in the middle: etoylike
but with very large scope, especially for media. This is the one you
need, but it isn't there (yet).

However, we also used etoys to try out a few ideas about object
organization and object building. Andreas, being an European, has a
better command of English than most of us. Andreas did not say that
you should try to do every project in etoys. He *did* say that there
are a lot of very useful ways of thinking about doing projects "in
the manner of etoys". Someday there will be "the middle environment"
mentioned above. Until then, you really need to do most projects
using the expert environment.

Cheers,

Alan
Post by Bill Spight
Post by Bill Spight
That sounds like what I did. Just to make sure, I tried again. I made a
new RectangleMorph, opened a viewer on it, and dragged out the script.
Then I made a new GoMorph, opened a viewer on it, got its tile, and
dropped in on the script.
Maybe my problem yesterday was not dropping it on the Rectangle tile. I
dropped it right on there. Nothing happened to the script, except it had
the Go tile sitting on in. No matter where I dropped, no effect.
What's wrong?
After a couple of more emails from Ned Konz, I tried again. As he
suggested, an empty script (^ self) is not enough. This time I made the
script, 'Rectangle hide', then dropped the Go tile over the Rectangle
tile, and made the replacement. So far so good.
I am doing this because I want to send a message to the GoMorph that I
see no way to do with the tiles available. So I switch the script to
morph to change the size of its board to 5 by 5. To my surpise (having
tried something like this before) the script is accepted. Now to run it.
not surprising. Why should it understand? And it's not too surprising,
but a bit dismaying, that all is not what it seems. Wheels within
wheels.
However, this whole excursion was in response to Andreas's notes
Post by Bill Spight
The point was usability and
efficiency.
Don't you realize that the Morphic that is perfect for
eToys *is* the one that is perfect for programmers?
To me, this is the logical result of many of the shortcomings of Smalltalk.
For example, subclassing for using the framework.
Given this, any attempt to "clean up" Morphic is doomed to fail if it does
not address the "usability issues" for the programmer. The best you can hope
for is a temporary effect but any newbie can (and therefore will!) write
code that breaks the framework. Some of this code will either be cool or
needed enough so that someone else is going to use it and you'll end up
exactly where we are right now.
Documentation, tests, etc. will (while being useful) not solve this problem.
Bridging this gap, making the "system
level" part of Squeak more like eToys is the thing that needs to be done. In
particular in the UI area since that's what most people will look at and
play with first, so it's the place where strong fences are most needed
(present in eToys).
I would love to work within the framework (whatever that is, exactly). I
like Morphic, it's why I'm here. :-)
But I need instance variables of types not among the 9 that are not
quite obviously available for scripting. I need more functionality (at
least, I think I do). I need better communication with Morphs than I
have seen. (It's probably available, but where?)
I'm a newbie, I made some Morphic subclasses, I broke the framework. So
sue me. Did I want to do that? No. Is Smalltalk the problem? Not for me.
Without it how could I have gone oven the fence to get done what needed
to be done? Is documentation or the lack thereof a problem? Not so much
for some people, but definitely for me.
I have a functioning GoBoardMorph (subclass), and a GoMorph (another
subclass) that is not fully functional yet, but it's getting there. Are
you cool with what I have done and am doing? Fine. No problem. If not,
and there seem to be those who are not, then help me out. I'm perfectly
willing to redo everything. Is that too much time and trouble? (It would
be for me.) OK, give me some good documentation. Is that too much time
and trouble? If so, what can I say?
Thanks for listening,
Bill
--
Richard A. O'Keefe
2012-01-28 11:20:25 UTC
Permalink
Ned Konz <***@bike-nomad.com> wrote:
You have to have a sentence already; you can replace its noun
(receiver or object) with the tile. Just drag the tile over the old
noun to change it.

Open a viewer on some other object, and drag out the sentence
"SomeObject start script script1". Drop it on the desktop. Now get a
tile from another object; you can drop that tile on SomeObject and
change the receiver of the start script message.

I do hope someone is harvesting these helpful hints.

I'm afraid the direct manipulation metaphor has been strained past its
breaking point here. We have Tiles which are like pointers to objects,
and dropping one Tile on another will do nothing or cause a replacement
depending on, stuff, I guess.

I tried the following.
1. Start up a fresh Squeak 3.2.
2. Make tiles for "A Word of Caution" (WC) and "ReadMe.txt" (RM).
3. Drag RM and drop it on WC. Nothing happens.
4. Halo/menu/embed. Now we have a WC tile with an embedded RM.
5. Halo/viewer on "SqueakLogo".
6. Drag (RM)WC and drop on "SqueakLogo" tile in "make sound croak"
script. Nothing happens.
7. Drag the "SqueakLogo make sound croak" script out onto the desktop.
8. W a i t while the script opens up. (250MHz Mac PPC)
9. Drag (RM)WC onto (SqueakLogo) in the script.
So I now have a script with
[[ReadMe.txt]A Word of Caution...] make sound [croak].
10. Click on the exclamation mark in the top left corner of the script.

OK, it croaks.

Try to pull the tile out of the script so I can use it in another
experiment. Eventually use "pick up" handle. Script promptly breaks,
and when I insist, vanishes. I had expected the original "noun" to
reappear.

It should not be too hard to make that work, surely?
I don't suggest that the "phrase" tile should remember the original
"noun", but the "script" morph that it's in certainly _does_ remember
"The Scriptee" (as the help balloon puts it), so if a phrase tile
finds itself without a receiver, couldn't it ask the containing script
for one?


Drag out "[SqueakLogo] turn by [5]". W a i t. Drop (RM)WC tile onto it.
Click on exclamation mark.

Now the "noun" of this command quite obviously mentions BOTH ReadMe.txt
AND A Word of Advice, but only the latter turns.

Trying to built up a "conjuction" of "nouns" like this seems an obvious
thing to do if you want several things to turn together. If it's not
going to work, maybe Tiles should refuse to accept Tiles?

I'm not sure what the best way to deal with that is.
Should some tile class override #addMorphFront:fromWorldPosition:
and if so which?

Let's go through the vanishing script process one more time.

1. Start a fresh Squeak 3.2
2. Open a viewer on SqueakLogo.
3. Drag "[SqueakLogo] forward by [5]" onto the desktop.
4. Grab [SqueakLogo] and move it onto the desktop.
Surprise! This time you get one of the desktop and there is
still one there again. (Black halo handle.)
5. Do it again.
Double surprise! Get "Syntax Error
Player50 scripts script1
script1
( expression expected ->forward: (5))"
6 Dismiss the error message by clicking on the X.
Surprise! Last time I tried this, the script disappeared.
This time it didn't!
7. Poke at it a bit, accidentally moving what's left of the phrase tile.
Error: subscript is out of bounds: 1
... TilePadMorph(Morph)>>firstSubmorph
PhraseTileMorph>>associatedPlayer
8. Sweep the broken vase under the carpet and run away to play outside,
hoping Mummy won't notice.

I don't think this is Pink Plane, I think it is Twilight Zone.

The thing that seems to be missing is
- a clear conceptual model of whether a phrase tile may have a
missing receiver or not.
- a failure to enforce this in the code at the right level.
That is, the code neither makes sure that there always _is_ a
receiver, nor works reliably when there _isn't_.

There is excellent balloon help for the items in the top row of
a script. There is good balloon help for the "verb" of a phrase.
But there isn't balloon help for the "subject" or for the phrase as
a whole, so you don't get to find out what you can do with this bit
the same way that, for example, you get to find out what the handles
in a halo do.

Since tiles don't seem to have any balloon help when on their own,
is there any way to get them to delegate balloon helpfulness to their
container, and give a tile pad some useful balloon help? I'd be happy
to submit something, but I don't understand this part of the system
well enough to do it.
Ned Konz
2012-01-28 11:20:30 UTC
Permalink
Post by Richard A. O'Keefe
I'm afraid the direct manipulation metaphor has been strained past
its breaking point here. We have Tiles which are like pointers to
objects, and dropping one Tile on another will do nothing or cause
a replacement depending on, stuff, I guess.
[snip description of using halos to do interesting things with tiles]
Post by Richard A. O'Keefe
It should not be too hard to make that work, surely?
I don't suggest that the "phrase" tile should remember the original
"noun", but the "script" morph that it's in certainly _does_
remember "The Scriptee" (as the help balloon puts it), so if a
phrase tile finds itself without a receiver, couldn't it ask the
containing script for one?
[snip more halo manipulation]
Post by Richard A. O'Keefe
Trying to built up a "conjuction" of "nouns" like this seems an
obvious thing to do if you want several things to turn together.
If it's not going to work, maybe Tiles should refuse to accept
Tiles?
They do, most of the time. That is, they only accept other tiles at
the right time when you do drag'n'drop.

BUT...

I think the problem is that there are two separate UI conventions at
work here. Nothing in the environment tells you that you can't mix
them, of course, which leads people (naturally) to try to (like you
did).

One is drag'n'drop, in which you get to see potential targets via
their highlighting, and can't drag non-draggable things. The
scripting/viewer interface is consistent (if a bit limited) in this
mode. You can drop noun tiles on other noun tiles to replace them
once they're in scripts. Other actions with the noun tiles are
futile. Once in a script, they can't be dragged back out.

The other UI -- the generic halo/menu UI for Morphs -- *looks* like it
should work (that would be consistent), and in fact you can get halos
on these things and manipulate them like you did, but this NEVER does
what you want. So -- despite the fact that the tools themselves are
built using Morphic -- using this generic interface is not what you
want. Halos aren't part of the scripting vocabulary when applied to
the scripting tools themselves.

In fact, I haven't seen any Morphic UI yet that attaches any kind of
high-level meaning to these low-level actions (embed into, duplicate,
grab, rotate...).

A simple solution for the viewer/scripting items would be just to make
them not pop up halos when blue-clicked.
--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE
Ned Konz
2012-01-28 11:20:31 UTC
Permalink
Post by Richard A. O'Keefe
I'm afraid the direct manipulation metaphor has been strained past
its breaking point here. We have Tiles which are like pointers to
objects, and dropping one Tile on another will do nothing or cause
a replacement depending on, stuff, I guess.
[snip description of using halos to do interesting things with tiles]
Post by Richard A. O'Keefe
It should not be too hard to make that work, surely?
I don't suggest that the "phrase" tile should remember the original
"noun", but the "script" morph that it's in certainly _does_
remember "The Scriptee" (as the help balloon puts it), so if a
phrase tile finds itself without a receiver, couldn't it ask the
containing script for one?
[snip more halo manipulation]
Post by Richard A. O'Keefe
Trying to built up a "conjuction" of "nouns" like this seems an
obvious thing to do if you want several things to turn together.
If it's not going to work, maybe Tiles should refuse to accept
Tiles?
They do, most of the time. That is, they only accept other tiles at
the right time when you do drag'n'drop.

BUT...

I think the problem is that there are two separate UI conventions at
work here. Nothing in the environment tells you that you can't mix
them, of course, which leads people (naturally) to try to (like you
did).

One is drag'n'drop, in which you get to see potential targets via
their highlighting, and can't drag non-draggable things. The
scripting/viewer interface is consistent (if a bit limited) in this
mode. You can drop noun tiles on other noun tiles to replace them
once they're in scripts. Other actions with the noun tiles are
futile. Once in a script, they can't be dragged back out.

The other UI -- the generic halo/menu UI for Morphs -- *looks* like it
should work (that would be consistent), and in fact you can get halos
on these things and manipulate them like you did, but this NEVER does
what you want. So -- despite the fact that the tools themselves are
built using Morphic -- using this generic interface is not what you
want. Halos aren't part of the scripting vocabulary when applied to
the scripting tools themselves.

In fact, I haven't seen any Morphic UI yet that attaches any kind of
high-level meaning to these low-level actions (embed into, duplicate,
grab, rotate...).

A simple solution for the viewer/scripting items would be just to make
them not pop up halos when blue-clicked.
--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE
Ned Konz
2012-01-28 11:20:31 UTC
Permalink
Post by Richard A. O'Keefe
I'm afraid the direct manipulation metaphor has been strained past
its breaking point here. We have Tiles which are like pointers to
objects, and dropping one Tile on another will do nothing or cause
a replacement depending on, stuff, I guess.
[snip description of using halos to do interesting things with tiles]
Post by Richard A. O'Keefe
It should not be too hard to make that work, surely?
I don't suggest that the "phrase" tile should remember the original
"noun", but the "script" morph that it's in certainly _does_
remember "The Scriptee" (as the help balloon puts it), so if a
phrase tile finds itself without a receiver, couldn't it ask the
containing script for one?
[snip more halo manipulation]
Post by Richard A. O'Keefe
Trying to built up a "conjuction" of "nouns" like this seems an
obvious thing to do if you want several things to turn together.
If it's not going to work, maybe Tiles should refuse to accept
Tiles?
They do, most of the time. That is, they only accept other tiles at
the right time when you do drag'n'drop.

BUT...

I think the problem is that there are two separate UI conventions at
work here. Nothing in the environment tells you that you can't mix
them, of course, which leads people (naturally) to try to (like you
did).

One is drag'n'drop, in which you get to see potential targets via
their highlighting, and can't drag non-draggable things. The
scripting/viewer interface is consistent (if a bit limited) in this
mode. You can drop noun tiles on other noun tiles to replace them
once they're in scripts. Other actions with the noun tiles are
futile. Once in a script, they can't be dragged back out.

The other UI -- the generic halo/menu UI for Morphs -- *looks* like it
should work (that would be consistent), and in fact you can get halos
on these things and manipulate them like you did, but this NEVER does
what you want. So -- despite the fact that the tools themselves are
built using Morphic -- using this generic interface is not what you
want. Halos aren't part of the scripting vocabulary when applied to
the scripting tools themselves.

In fact, I haven't seen any Morphic UI yet that attaches any kind of
high-level meaning to these low-level actions (embed into, duplicate,
grab, rotate...).

A simple solution for the viewer/scripting items would be just to make
them not pop up halos when blue-clicked.
--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE
Mike Thomas
2012-01-28 11:20:27 UTC
Permalink
Hi Ned.

| I just did this successfully:
|
| * make a Rectangle and an Ellipse.
| * open up the Rectangle's viewer.
| * pull out the sentence "Rectangle's color <- {red patch}"
| * drop the sentence on the desktop; it becomes a script.
| * get a tile for the Ellipse.
| * drop the Ellipse tile on the Rectangle's tile in the script
| * run the script: the Ellipse turns red.

I did this and it worked as described. However, the Scriptee name in the
top row of the script remains as "Rectangle".

What is the implication of that? For example, is the scriptee really the
rectangle or is it the ellipse? Is the rectangle just sending a message to
the ellipse?

Is it possible to change the Scriptee name?
Ned Konz
2012-01-28 11:20:30 UTC
Permalink
Post by Mike Thomas
Hi Ned.
|
| * make a Rectangle and an Ellipse.
| * open up the Rectangle's viewer.
| * pull out the sentence "Rectangle's color <- {red patch}"
| * drop the sentence on the desktop; it becomes a script.
| * get a tile for the Ellipse.
| * drop the Ellipse tile on the Rectangle's tile in the script
| * run the script: the Ellipse turns red.
I did this and it worked as described. However, the Scriptee name
in the top row of the script remains as "Rectangle".
Yes. That's the object that owns the script.
Post by Mike Thomas
What is the implication of that? For example, is the scriptee
really the rectangle or is it the ellipse?
It's the rectangle.
Post by Mike Thomas
Is the rectangle just
sending a message to the ellipse?
Yes.
Post by Mike Thomas
Is it possible to change the Scriptee name?
I don't think so, other than changing the name of the original object
for which you constructed a script.
--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE
Ned Konz
2012-01-28 11:20:30 UTC
Permalink
Post by Mike Thomas
Hi Ned.
|
| * make a Rectangle and an Ellipse.
| * open up the Rectangle's viewer.
| * pull out the sentence "Rectangle's color <- {red patch}"
| * drop the sentence on the desktop; it becomes a script.
| * get a tile for the Ellipse.
| * drop the Ellipse tile on the Rectangle's tile in the script
| * run the script: the Ellipse turns red.
I did this and it worked as described. However, the Scriptee name
in the top row of the script remains as "Rectangle".
Yes. That's the object that owns the script.
Post by Mike Thomas
What is the implication of that? For example, is the scriptee
really the rectangle or is it the ellipse?
It's the rectangle.
Post by Mike Thomas
Is the rectangle just
sending a message to the ellipse?
Yes.
Post by Mike Thomas
Is it possible to change the Scriptee name?
I don't think so, other than changing the name of the original object
for which you constructed a script.
--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE
Ned Konz
2012-01-28 11:20:31 UTC
Permalink
Post by Mike Thomas
Hi Ned.
|
| * make a Rectangle and an Ellipse.
| * open up the Rectangle's viewer.
| * pull out the sentence "Rectangle's color <- {red patch}"
| * drop the sentence on the desktop; it becomes a script.
| * get a tile for the Ellipse.
| * drop the Ellipse tile on the Rectangle's tile in the script
| * run the script: the Ellipse turns red.
I did this and it worked as described. However, the Scriptee name
in the top row of the script remains as "Rectangle".
Yes. That's the object that owns the script.
Post by Mike Thomas
What is the implication of that? For example, is the scriptee
really the rectangle or is it the ellipse?
It's the rectangle.
Post by Mike Thomas
Is the rectangle just
sending a message to the ellipse?
Yes.
Post by Mike Thomas
Is it possible to change the Scriptee name?
I don't think so, other than changing the name of the original object
for which you constructed a script.
--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE
Continue reading on narkive:
Loading...