Hello,
at v4, etoys mode:
- create an instance, of ellipse for example, - create a script with the order (cat. miscellaneous) do menu item_adhere to edge... - run the script then (and not before) appear the menu with options (bottom, left...) but you never more can clear of it.
regards
On Oct 22, 2008, at 1:44 AM, antonio wrote:
at v4, etoys mode:
- create an instance, of ellipse for example,
- create a script with the order (cat. miscellaneous) do menu
item_adhere to edge...
- run the script then (and not before) appear the menu with options (bottom,
left...) but you never more can clear of it.
Indeed.
"Do menu item" offers the opportunity to execute any menu item contained in an object's "halo menu" programatically.
Most menu items are fine to use this way, even in a ticking script, because they simply execute. But some menu items result in a secondary prompt or menu being put up, and when invoking such a menu item in a continuously-running (ticking) script, the follow-on prompt or menu will continuously be put up, so that your user will always be in a state of needing to respond to the prompt or menu, thus denying her the chance to do anything else interactively.
So... There are various ways in etoys that you can "hose yourself", particularly through injudicious use of a ticking script. This is a good example.
We could, case by case, try to reduce the number of such danger points, but I don't think we can altogether eliminate them without unacceptably limiting the expressive power of the system. (e.g. in this example, there's no problem at all unless/until the user chooses to set the script to "ticking"...)
One proposal (from Yoshiki) to reduce the chance of abuse of "do menu item" is not to offer "do menu item" in the viewer unless the eToyFriendly flag is turned off. What do people think of that idea?
Cheers,
-- Scott
On Thursday 23 Oct 2008 3:31:19 am Scott Wallace wrote:
One proposal (from Yoshiki) to reduce the chance of abuse of "do menu item" is not to offer "do menu item" in the viewer unless the eToyFriendly flag is turned off. What do people think of that idea?
A menu is just a collection of action buttons. If we had a way to assemble tiles around actions on the fly, then we could invoke the action directly.
E.g. drop a menu button into a TileMakerMorph or scriptor to create a command tile out of target/selector/arguments.
Subbu
Is not possible to get the control after neither with Alt +. !?
Most of students says EtoyFriendly is "too much shamefaced" for them, and do menu item is wonderful, this is clear for me. Perhaps it is only a question of a specific balloon help at do menu item (not only the actual "do the menu item"), something like: ".... Warning: if..."
cheers
El mié, 22-10-2008 a las 15:01 -0700, Scott Wallace escribió:
On Oct 22, 2008, at 1:44 AM, antonio wrote:
at v4, etoys mode:
- create an instance, of ellipse for example,
- create a script with the order (cat. miscellaneous) do menu
item_adhere to edge...
- run the script then (and not before) appear the menu with options (bottom,
left...) but you never more can clear of it.
Indeed.
"Do menu item" offers the opportunity to execute any menu item contained in an object's "halo menu" programatically.
Most menu items are fine to use this way, even in a ticking script, because they simply execute. But some menu items result in a secondary prompt or menu being put up, and when invoking such a menu item in a continuously-running (ticking) script, the follow-on prompt or menu will continuously be put up, so that your user will always be in a state of needing to respond to the prompt or menu, thus denying her the chance to do anything else interactively.
So... There are various ways in etoys that you can "hose yourself", particularly through injudicious use of a ticking script. This is a good example.
We could, case by case, try to reduce the number of such danger points, but I don't think we can altogether eliminate them without unacceptably limiting the expressive power of the system. (e.g. in this example, there's no problem at all unless/until the user chooses to set the script to "ticking"...)
One proposal (from Yoshiki) to reduce the chance of abuse of "do menu item" is not to offer "do menu item" in the viewer unless the eToyFriendly flag is turned off. What do people think of that idea?
Cheers,
-- Scott
On Oct 23, 2008, at 1:26 AM, antonio wrote:
Is not possible to get the control after neither with Alt +. !?
As long as a runaway script keeps "ticking", a debugger brought up by alt-dot can never retain control long enough to be operated, because there's always another menu getting put up by the ticking script, which seizes control of the UI. So the user is stuck.
To address this kind of problem, Alt-dot really *should* stop all the ticking scripts in the project -- not only as a remedy for pathological situations like the one we've been discussing, for which there's presently no graceful escape, but also, generally, as a quick way to suspend any running simulation, i.e., the equivalent of pressing the red "Stop" button in the "all scripts" tool.
I've opened a TRAC ticket for this:
https://dev.laptop.org/ticket/8879
... and I've posted a potential fix there which implements the above suggestion, for comment.
Cheers,
-- Scott
etoys-dev@lists.squeakfoundation.org
-
antonio -
K. K. Subramaniam -
Scott Wallace