SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

Mantis - Squeak
Viewing Issue Advanced Details
1780 Morphic tweak always 09-11-05 05:41 01-09-09 23:53
wiz  
matthewf  
low  
@60@ 3.8  
fixed  
none    
none  
0001780: Stay up menus have a confusing and dangerous behavior when obscured.
For this one.
Pop up a world menu.
Make is stay up by removing the pin.

Get a workspace. Or add browsers.

Stay up menus have a low z order so they easily get obscured.

Obsure the menu items but let the left half of the menu show.
I.E. you can see the menu but have no idea what the menu item
is showing.

Now click on a menu item.

The MENU ITEM ACTIVATES.

This is what makes this a major problem. If you are unlucky you could save an experimental image over a safe checkpoint image.

Or any of the other wonderful things that menus can do.

This is potentially very dangerous. And spoils stay up menus as a working option.

The correct behavior IMHO is that clicking on any item in an obsucured menu should "activate" the menu like a system window. Bring it to the front and then clicking on an item should activate that item.

This is what happens if you click the header of the menu but not the items of the menu.
related to 0006687assigned matthewf MenuMorphs are too easy to pick up 
related to 0006699new  Menu keyboarding works poorly and conflicts with menu label editing 
related to 0005608closed matthewf preference #menuTitleBorderWidth - MenuMorph bugfix 
related to 0006690new  The "Active window" is stored in the SystemWindow class rather than the world 
related to 0006791assigned wiz Keyboarding on a menu is trying to serve two conflicting purposes. 
child of 0006635new  Mother of Squeak UI annoyances 
child of 0006530new  A mother for button, slider and menuItem targeting and argumenting related reports. 
 BringMenuToFrontHack.1.cs [^] (862 bytes) 09-20-07 05:22
 MenuMorph-BetterMouseHandling.1.cs [^] (6,117 bytes) 09-20-07 12:49
 MenuMorph-BetterMouseHandling.2.cs [^] (3,518 bytes) 10-09-07 23:16

Notes
(0002638)
laza   
09-11-05 10:46   
I think the problem is, that the morphicLayerNumber will not have an effect after moving a window from one place to another. As one can see in MenuMorph, pinned (stayUp) menus have the highest morphicLayerNumber 100. But a SystemWindow will be readded to the world after a move with addMorphFirst:, which makes it the top most morph regardless of any morphicLayerNumber. So pinned menus and flaps can get obscured by system windows, even when they are intended to stay above them.
(0003552)
acon   
01-19-06 10:10   
If the comment in MenuMorph>>morphicLayerNumber is correct, higher numbered layers are placed behind lower numbered layers. The code in said method places pinned menus in the default layer, since normal morphs are also placed in layer 100. If this is as it should be, pinned menus should be obscurable by windows.
(0003554)
laza   
01-19-06 15:38   
I think I should have written 10 and not 100, but I can't remember. But the problem is still the the same if you change the mehtod for pinned menus to have a morphicLayerNumber of 10.
(0003576)
wiz   
01-20-06 07:33   
Hi laza and acon.

Thanks for your interest.

The desired behavior for pinned menu items is that unless they are in an activated menu clicking on them should activate and bring the menu to the front and no other action. Then if clicked when actived they should perform the menu action.

This behavior would be similar to a system window behavior.

Right now to get that behavior you have to click on the menu header or a line item.

So items need to ask amIactivated and if not ask their menu owner to activate.

something like:

self owner areWeActivated

ifTrue: [ ^self boyDoIKnowHowToBeActive]
ifFalse: [ ^self owner whyNotActivateUs ]

Cheers - Jerome Peace
(0011167)
matthewf   
09-20-07 05:27   
Uploaded a quick hack to make this work. Ideally, a sticky MenuMorph should behave like a SystemWindow, ie, be able to be the single active entity in the world. This is not possible, as that facility is closed to morphs other than SystemWindow. The "active" window is actually handled as a class variable of SystemWindow, rather than as a property of the world, so it is quite "hackish" itself. (reported as bug 0006690)

The only issue with this hack is that the menu will stay on top until you activate another system window, or drag the currently active one, to bring it back "on top"

(0011171)
matthewf   
09-20-07 12:50   
This bug interacts with 0006687. See there for more information. Uploaded MenuMorph-BetterMouseHandling which fixes both bugs at once
(0011172)
matthewf   
09-20-07 12:57   
The fix for this issue is slightly messy, but I can't think of a better way to do it without signifigantly changing SystemWindow. In MenuItemMorph>>mouseDown: , I query world to see if the owning menu is underneath anything else, and if so, bring the owning menu to the front and exit without activating or giving mouse focus to the owning menu.

(0011173)
matthewf   
09-20-07 13:05   
The "issue" that the menu stays in front if it overlaps the currently active SystemWindow already existed without this fix. To demonstrate it, open a world menu very close to the active window, so that it partially obscures the active window, then make the menu sticky. You can still interact with the partially-obscured window. Fixing this would depend on bug 0006690 to be fixed.

If this were fixed by promoting sticky menus to be activated/passivated like SystemWindows, you would always have to click twice to use a sticky menu; once to activate the menu, whether it is obscured or not. The first click would activate the menu and passivate the previously active window, the second click would activate the clicked item. Not sure whether that would be preferable or not

(0011179)
wiz   
09-23-07 02:13   
Hi Matthew,

Thanks for taking a run at this.

While I haven't tried the code yet I took a quick look at it. You are not doing anything with MenuItemMorphs and I suspect that is where the problem is at least for the activate-while-still obscured bug.

Also I still claim this is of major severity. It is not a tweak. The bug is real and dangerous since it can wipe out a saved image. The exact circimstances for this to occur are rare but a heavy programmer will run into once too often every few years.

The way to mark this is major severity ( heavy impact on users)
 and low priority (which deals with when it will get fixed).
Consider the two terms to be mostly orthoganal.

This problem has been on a back burner for me exactly because I need to know more about menus inorder to come up with a good fix (one that sticks). Maybe a good step would be working on an sunit test that demo's the problem and which a fix can pass.

Yours in curiosity and service, --Jerome Peace

P.S. [OT] Thanks Matthew for taking responsibility for organizing and collecting the reports. Its good to have an someone else who "gets" how important it is to use mantis well and fully.

Cheers --Jer
(0011180)
matthewf   
09-23-07 03:09   
hi wiz. Not sure what code you are looking at, but the code modifies MenuItemMorph>>mouseDown:. There is no simple query isOnTop or anything, so I do a quick search of all top-level morphs to see if any are above my menu. It seems to work. just file it in and test. The short change set (bringMenuToFrontHack.cs) is just one method and fixes this bug; the longer one (MenuMorph-betterMouseHandling.cs) fixes both this bug and 0006687 at once, since they kind-of interfere
(0011202)
wiz   
09-25-07 05:44   
Hi Matthew,

I am not refering to any specific code. I have not made a study of this problem yet.

My notion was that the events were being passed to the MenuItemMorphs and they were activating. From what you say that notion seems to be wrong.

Is it the case that the event goes directly to the menu. The menu then uses the event position to select the menu item in question, Highlight the item and perform the items action?

If that's so, then you are probably on the right track and I should pipe down and just try the code.

Cheers, -Jer
(0011203)
matthewf   
09-25-07 06:58   
Yes, when an event is sent, it goes to the most specific morph under the hand, and, in this bug, that morph is a MenuItemMorph. I'm not sure, but I don't think the menu gets a chance to see the event before the MenuItemMorph does. Thus, this fix is implemented entirely within MenuItemMorph>>mouseDown:.
(0011208)
wiz   
09-25-07 22:41   
Hi Matthew,

Ha. I was more confused by your answer that I was before. The cure was the same play with the code, then understand.

I really like that you solved my problem and the menu will come to front before the items get activated. Kudos and a good fix.

Now the other uncovered problems. Menu keyboarding.
If you have the shift key down when you press the mouse the label editor activates (menu becomes twice as wide with the selection you are on highlighted once in red then in black . You can type one letter and that replaces the label. Subsequent typing "filters the menu" by elimiating labels that do not match what is typed.

Basicly this is two features in confilct.

One circa 1999 (di and ar) meant to allow dynamicly changing menu labels.

The other added later meant for selecting menu items via keyboard input.

The second steals and hordes keyboard focus after the first keystroke.

I haven't looked for the problems but it would seem the next step is to decide what is to go. I supect the label editing feature should be eliminated for now.

(0011277)
matthewf   
10-09-07 23:15   
Added the fix for 0005608 to MenuMorph-BetterMouseHandling.2.cs, since 0005608 was added to the 3.10 update stream, and 0006687 interferes with that one (both modify MenuMorph>>addTitle:icon:updatingSelector:updateTarget:)
(0011278)
matthewf   
10-09-07 23:29   
I've been using this fix for a while now to see if it has any issues. One issue I have found is that when a menu (any menu) is underneath an always-on-top morph (like an interupted ProgessMorph), it will never be able to be activated until either the menu or the on-top morph is moved
(0011481)
edgardec   
11-26-07 10:22   
I beg both test 3.10.1 once you have 7158 update.
If any code for this and related *0005608* is missed, then send me a note saying wich .cs I must take and do the Monticello for current release
(0011699)
matthewf   
01-22-08 06:40   
"fix begin"
Installer mantis bug:1780 fix:'MenuMorph-BetterMouseHandling.2.cs'.
"fix end"

(0011976)
kbrown   
04-08-08 00:39   
As part of LPF + MinorFixesUnstable, loading 1780 into sq3.10-7159dev08.04.1appears to cause an anomaly with System Browser 'find class', if there are multiple choices, they cannot be selected.

Offending Installer script entry is:
" http://bugs.squeak.org/view.php?id=1780 [^] "
Installer mantis ensureFix: '1780: Stay up menus have a confusing and dangerous behavior when obscured.'.
"kph: not sure this works as intended, menus cease to work at all if partially obscured"
(0011979)
matthewf   
04-08-08 04:36   
Ok. this patch interacts nastily with the chooser in Pinesoft Widgets UIManager. To reproduce:
- Get an image with Pinesoft widgets. squeak-dev-beta has it
- Open a class browser (ST80 or OB; it doesn't matter)
- try finding the class 'morph'
- You should get a huge list with lots of columns

Without MenuMorph-BetterMouseHandling.2.cs: you are able to click on any item in the columns and it activates

With MenuMorph-BetterMouseHandling.2.cs: clicking on any item rearranges the columns, and does not activate the item

I'll have to look into this
(0011980)
matthewf   
04-08-08 04:56   
hmm. This fix is already included in the Pinesoft-Widgets package. It was included at some point between Pinesoft-Widgets-gvc.263 and Pinesoft-Widgets-gvs.272, in the squeaksource repository: http://www.squeaksource.com/UIEnhancements/ [^] . The widgets package has logic to not enable the bring to front behavior if the menu is not a direct child of world, which fixes the issue reported by Ken Brown

(0011981)
matthewf   
04-08-08 05:51   
"fix begin"
((Smalltalk includesKey: #MCPackage)
and: [MCWorkingCopy registry includesKey: (MCPackage named: 'Pinesoft-Widgets')])
ifFalse: [Installer mantis bug: 1780 fix: 'MenuMorph-BetterMouseHandling.2.cs'].
"fix end"
(0011985)
GazzaGuru   
04-08-08 22:31   
Hi Matt. The fixes were incorporated in Pinesoft-Widgets-gvc.268. I can upload that and surrounding versions to SqueakSource if you want.
(0011986)
matthewf   
04-09-08 00:12   
Hi Gary. It would be nice to have all the versions available, but don't hurt yourself. I don't know of a way to do this in bulk
(0011987)
GazzaGuru   
04-09-08 12:31   
I've filled in the gaps from version Pinesoft-Widgets-gvc.260 onwards.
(0012577)
Keith_Hodges   
09-03-08 14:03   
"fix begin"
PackageOrganizer default packageNamed: 'Pinesoft-Widgets' ifAbsent: [
Installer mantis bug: 1780 fix: 'MenuMorph-BetterMouseHandling.2.cs'].
"fix end"