Mantis - Squeak
Viewing Issue Advanced Details
2496 Morphic minor always 01-16-06 04:54 03-14-06 16:11
aking PM 1.7 Ghz  
Linux  
normal 2.6.14.2  
closed 3.9  
6713 fixed  
none    
none 3.9  
0002496: Can't open world menu after halo's opened
Right click on the background and bring up the halos. Left or middle click to cancel them. From then on, left click or middle click will not bring up a popup menu. I have to press ESC or move a window before it starts working again.
1Gb RAM, Gentoo 2005.1
related to 0006975new  [RFE] Better event distictions between drag, click and mouse up. 
 HandMorph-removeHalo.st [^] (224 bytes) 01-20-06 01:04
 PasteUpMorph6729-mouseDown.st [^] (2,006 bytes) 02-23-06 07:09
 WorldMenuPopupFix-wiz.1.cs [^] (3,383 bytes) 02-25-06 07:56

Notes
(0003572)
acon   
01-20-06 01:07   
Added a fix for this issue. The halo wasn't removed from the hand, only from its owner.

Why is the opening of the world menu delayed if the world has a morph?
(0003968)
wiz   
02-22-06 07:50   
Ha, you've found the smoking gun. (A bug that shows why doubleclick logic must be changed.)


Try this.
>Right click on the background and bring up the halos.
>Left or middle click to cancel them.
>From then on, left click or middle click will not bring up a popup menu.
Yes.
But now left press and drag. The menu appears!

Alternately press and hold the mouse down w/o moving it. The menu appears!

These facts place this bug at the doorstep of clickstate
and the interaction of focus and click state.

Other related mantis bugs are Mantis 0001037 and 0001567 the latter has a preliminary update the clickstate code. Which may point to a way to correct this problem.

(0003969)
wiz   
02-22-06 09:07   
Ah well. Maybe not a smoking gun after all.

Look at the pasteup morph mouseDown and mouseUp actions.

Apparently after halos are pressed mouseDown in world will set a delayed WorldMenu alarm.
Mouseup will cancel it.
So clicking will usually set and cancel the world menu because of the mouse up action.

Once the state is not affected by a recent world halo the mousedown will cause immediate popup of the world menu thus clicking will seem to work.

The mouseDown action was long and complicated an I haven't really looked closely at it yet. Its a good candidate for some rewriting though just based on its length and complexity.

"Old bugs never die. They just become specs."

Yours in service, -- Jerome Peace
(0003993)
wiz   
02-23-06 07:07   
Hi acon

You got the problem right in one. But maybe not the reason for it.
Historical research (Good ole 39.a with all changes from 3.0 )
Shows that the bug was introduced when dgd mistook:

self hand halo: nil "Which causes the hand to forget its halo. i.e. shake it off."

to mean the same thing as:

self hand removehalo. "Which I believe deletes the handMorphs halo if it is showing one."

He had a tendency to "fix things where they weren't broken" for the sake of clarity. Here he got the messages wrong.

I've uploaded a cs that reverts That line of PasteupMorph's mouseDown: to do the proper thing with the hand.

Your code will fix the problem but it may cause others. The hand in not the proper thing to send removeHalos to. Have you ever seen an hand with its own halos? I believe undoing dgd's change is the correct fix in this case.

>Why is the opening of the world menu delayed if the world has a morph?
    
That is a good question. I'm not sure why this is being done yet. It would make sense if you delayed a menu on mouse down so that mouse up would not activate a random menu item. I don't know if that meets the circumstances here. There have been five different authors mucking in this particular method. Someone may have been trying to preserve a piece of logic they didn't fully understand.

Uploading

PasteUpMorph6729>>mouseDown.st

This changes just the line I've mentioned here. It works a charm for fixing the symptom.

(0004084)
wiz   
02-25-06 08:06   
From the preamble:

'From Squeak3.9alpha of 4 July 2005 [latest update: 0007002] on 25 February 2006 at 12:45:27 am'!
"Change Set: WorldMenuPopupFix-wiz
Date: 25 February 2006
Author: (wiz) Jerome Peace
            
            
Fixes
Mantis bug 0002496 can't open world menu after halo's.

dgd was trying to allow easy selection on mouse down in a world morph. In restructuring the logic in PasteupMorph>>mouseDown: he 'cleaned up' the code for shaking of the mouse halo mistaking shaking with removing the halo. This left the halo deleted but unshaken which caused the boolean hand had haloes to get stuck and the menu not to appear when the mouse was clicked a second time.

That fixed I had a closer look at the logic and decided a redo was in order. So first I reverted to the previous version (You have to find it in 3.9a with all changes from 3.0) Then I added much gentler logic to achieve the easy selection. Along the way I separated out the predicate for easy selection so that it can easily be maintained w/o any more harm to the poor overworked mouseDown method.

I also restricted easy selection to world morphs. I remember it made a mess when used in a holder. And anyway the forced selection is still availible (shift drag).

It may be desirable in the future to extend easy selection to playfields. If so please amend the predicate and leave the mouseDown intact.

Yours in service --Jerome Peace

This supercedes the other fix I uploaded. I think it does a pretty good job of making the behavior work as intended rather than as written. And it will be a heck of a lot easier to adjust.

P.S. The reason for the delayed invocation of mouse up

clicking on the world removes the halos (from what ever morph they are on) and does nothing else.

mousedown hold on the world removes halos and brings up the menu.

As does clicking on the world when there are no halos present.
(0004096)
cdan   
02-25-06 19:15   
I have just stepped on this bug too. Maybe it helps to know that the bug is not present in 3.6 and 3.7 but we can find it in 3.8.
(0004471)
MarcusDenker   
03-14-06 16:11   
7008