[Etoys-notify] [JIRA] Commented: (SQ-143) Make it less easy to rip a BookMorph's nav-bar out of the book
jira at immuexa.com
jira at immuexa.com
Mon Apr 13 16:33:21 EDT 2009
[ http://tracker.immuexa.com/browse/SQ-143?page=comments#action_33966 ]
Scott Wallace commented on SQ-143:
The fix has been pushed to the olpc-etoys update stream as update 2212haloClickweak-sw.
> Make it less easy to rip a BookMorph's nav-bar out of the book
> Key: SQ-143
> URL: http://tracker.immuexa.com/browse/SQ-143
> Project: squeakland
> Type: Improvement
> Components: etoys
> Reporter: Scott Wallace
> Assignee: Scott Wallace
> Priority: Eventual
> Fix For: M1: first alpha (may)
> Attachments: haloClickTweak-sw.3.cs.gz
> From TRAC Ticket #8151 (Tim Falconer, Aug 2008, 'have etoys book navbar "resist being picked up"'
> (tim) A fairly frequent occurrence is for children to accidentally remove a book's navbar, thinking they're moving the book itself. Can we default to the navbar being in a "resist being picked up" state?
> (yoshiki) Because kids brought up the halo for the menu bar, black handle or pink handle just bypass the "resist being picked up" flag; so it wouldn't help. In the mean time, they can toggle "page controls visible" checkbox in the "book..." menu (in the white menu handle) to reinstate it. And, we can probably make a special case in the halo order in a book so that the menu bar's halo comes after book's.
> (scott) As Yoshiki wrote, changing the setting of "resist being picked up" wouldn't make a difference.
> AFAIK in all current etoys versions, if you grab a book by its nav-bar, it picks up the book -- it *doesn't* rip out the nav-bar. The only way you can actually rip the nav-bar out of the book is by the pretty conscious action of bringing up the halo on the nav-bar, then grabbing it by the black handle, or dismissing it by the pink "X" handle. And, for better or worse, a fundamental feature throughout Morphic is that you can get a halo on any object and from that halo do many kinds of drastic things, such as ripping necessary subparts out and putting them somewhere else or discarding them altogether.
> I agree with Yoshiki's suggestion that if a first halo-click when the mouse is over the book's nav-bar were to bring up the halo on the entire book, it might reduce accidental removals of the nav-bar... Maybe that's worth taking a look at, though the code for deciding who gets the halo on which click has passed through many hands over the years and is pretty fragile by now...
> (scott) However, it's perhaps a bug that the black halo handle is shown even if an object is marked "resist being picked up" -- though strictly speaking "resist being picked up" refers not to halo use but to what should happen if the user attempts a simple mouse drag.
> If that were deemed a bug, and if the bug were fixed, then situations that this ticket directly refers to -- user halo-clicks on the book, intending to move book, but halo comes up on the book's nav-bar instead, and user grabs it by the black halo handle, with the result that the nav-bar is ripped out of the book) -- would be avoided.
> (scott) Also, it's noteworthy that although a book can always be directly moved by simply dragging its nav-bar, kids seemingly often don't know or think to do that, but instead tend to move objects using the halo.
> (karl) I think the original report maybe want a 'halo click' on the nav bar to bring up the halo on the whole book, just like a SystemWindow does with a 'halo click' on it's title bar. That seems like the most intuitive way for it to work for me, too.
> (scott) Yes, understood, and we should try to do that. The parallel with the SystemWindow case makes the change sound misleadingly simmple, however. For SystemWindows, it always makes sense for the first halo-click to bring up the halo on the whole window, and for successive clicks to work their way in For a Book, if the first halo click happens on some morph in the interior of a book-page, however, we want the halo to go right onto the item on that page, rather than on the outer book (for years it *was* the other way...). So some extra special-casing is needed here, in already convoluted code...
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:
More information about the Etoys-notify