Hi all,
If the delay in getting a world menu is troubling, try the enclosed change set. The change is that if the were no halos, then the menu pops up right away. If people like this, I will lobby for inclusion.
Cheers, Bob
On Mon, 18 Dec 2000 16:02:04 -0500 Doug Way dway@riskmetrics.com wrote:
But I have a feeling that what you're seeing are some 200ms delays which were added to some operations in Morphic. For example, bringing up the World menu now requires that you hold down the button for at least 200ms before it pops up. I think this was done as a simple implementation so that a "quick click" on the desktop would shake off halos. I also notice that this delay is now in PluggableListMorphs too, so that selecting a list item always takes at least 200ms in a Browser, for example. (I'm not sure why this was added here.)
For what it's worth, I think that these 200ms delays are a VERY BAD idea from a "feel" perspective. It gives the impression that Morphic is slow when it really isn't. (The only case of a delayed pop-up menu in a UI that I can think of is with something like Netscape on the Mac, where if you hold down a mouse on a link, a pop-up menu eventually appears, as opposed to a quick click which simply follows the link. But that delay is much more justifiable than the ones in Squeak, IMHO.)
I think it should be possible (although slightly more complicated) to implement things so that a 200ms delay in opening the World menu isn't necessary, but halos are still shaken off. I actually implemented a changeset which did most of this a few months ago, but it was made obsolete by the significant changes to Morphic in the last couple months. Maybe I'll take another stab at it, unless someone else wants to try.
=====code follows===== 'From Squeak2.9alpha of 17 July 2000 [latest update: #3187] on 18 December 2000 at 4:12:44 pm'!
!PasteUpMorph methodsFor: 'event handling' stamp: 'RAA 12/18/2000 16:12'! mouseDown: evt "Handle a mouse down event." | grabbedMorph handHadHalos | grabbedMorph _ self morphToGrab: evt. grabbedMorph ifNotNil:[ grabbedMorph isSticky ifTrue:[^self]. self isPartsBin ifFalse:[^evt hand grabMorph: grabbedMorph]. grabbedMorph _ grabbedMorph partRepresented duplicate. grabbedMorph restoreSuspendedEventHandler. (grabbedMorph fullBounds containsPoint: evt position) ifFalse:[grabbedMorph position: evt position]. "Note: grabbedMorph is ownerless after duplicate so use #grabMorph:from: instead" ^evt hand grabMorph: grabbedMorph from: self].
(super handlesMouseDown: evt) ifTrue:[^super mouseDown: evt]. handHadHalos _ evt hand halo notNil. evt hand halo: nil. "shake off halos" evt hand releaseKeyboardFocus. "shake of keyboard foci" evt shiftPressed ifTrue:[ ^evt hand waitForClicksOrDrag: self event: evt selectors: { #findWindow:. nil. #dragThroughOnDesktop:} threshold: 5]. self isWorldMorph ifTrue: [ handHadHalos ifTrue: [^self addAlarm: #invokeWorldMenu: with: evt after: 200]. ^self invokeWorldMenu: evt ]. "otherwise, explicitly ignore the event if we're not the world, so that we could be picked up if need be" self isWorldMorph ifFalse:[evt wasHandled: false]. ! !
Bob Arning wrote:
Hi all,
If the delay in getting a world menu is troubling, try the enclosed change set. The change is that if the were no halos, then the menu pops up right away. If people like this, I will lobby for inclusion.
This like the best solution to me Karl
Karl Ramberg wrote:
Bob Arning wrote:
Hi all,
If the delay in getting a world menu is troubling, try the enclosed change set. The change is that if the were no halos, then the menu pops up right away. If people like this, I will lobby for inclusion.
This like the best solution to me Karl
Yes, this looks great. This is basically what my earlier changeset attempted to do. You can shake off halos with one quick click, and then bring up the world menu with a second quick click. (Or, you can hold down the button to do both.)
(Any word on why the delay is now also there in PluggableListMorphs?)
- Doug Way dway@riskmetrics.com
Hi all,
I believe any artificial waits unless they are well below any perception threshold are really bad.
Is there a particular reason why one does not make halos go away the way one made them appear, i.e., by an alt-click on them? Maybe I want to invoke the world menu without the halos going away.
I am not following the 2.9 updates but I noticed with Squeak 2.8 and even VisualWorks that one sometimes has to wait for the UI to catch up with one's mouse clicks, i.e., you have got to keep the mouse button down for some ever so slight extended period of time or it is missed.
As bad as Windows is in other aspects it has become very responsive and I suspect one will never just work with Squeak alone but always with a heterogeneous set of tools Squeak being just one in the set, albeit hopefully the most prominent and useful one.
Therefore, I think one should strive to make it as responsive as the other GUIs we know and artificial delays are leading in the wrong direction.
BTW, dragging with mouse-buttons down is a suboptimal gesture, IMHO. In the Eiffel environment the right button was used to start dragging with one click and stop dragging with another terminating click. If you dropped, e.g., a class name into the pane where it appeared, the pane showed the class definition, i.e., dragging with source location=target location became a double click. Although it took me a little while to get used to the increased number of clicks, the benefit of not being forced to press *and* move anymore was certainly large. The right mouse button in Squeak should be reserved for context sensitive menus but it may be worth a try to initiate dragging with a 'your key'-click and terminate it with a normal click.
Regards,
Thomas
-- Dr. Thomas Kuehne 0178 4314387, http://www-agce.informatik.uni-kl.de/~kuehne The difficulty in doing research is to find the right questions so that all the answers come easily. -- TK
Thomas Kuehne wrote:
I believe any artificial waits unless they are well below any perception threshold are really bad.
Agreed. (Or at least, they should be a very last resort.)
Is there a particular reason why one does not make halos go away the way one made them appear, i.e., by an alt-click on them? Maybe I want to invoke the world menu without the halos going away.
Continuing to alt-click (blue-click) actually cycles through the halos of the various submorph layers that your mouse is over, so it probably wouldn't work as a way to toggle halos on and off.
You have a point about being able to invoke the world menu without the halos going away, but mostly I think of halos as a very temporary UI element... something that you usually use immediately after bringing up. So, having them disappear when you attempt to do anything else significant seems reasonable to me.
- Doug Way dway@riskmetrics.com
squeak-dev@lists.squeakfoundation.org