Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0001780 [Squeak] Morphic tweak always 09-11-05 05:41 01-09-09 23:53
Reporter wiz View Status public  
Assigned To matthewf
Priority low Resolution fixed  
Status pending   Product Version 3.8
Summary 0001780: Stay up menus have a confusing and dangerous behavior when obscured.
Description 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.

Additional Information 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.
Attached Files  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

- Relationships

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

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. 

- Notes
(0002638 - 480 - 480 - 480 - 480 - 480 - 480)
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 - 313 - 319 - 319 - 319 - 319 - 319)
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 - 183 - 183 - 183 - 183 - 183 - 183)
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 - 681 - 795 - 795 - 795 - 795 - 795)
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 - 589 - 643 - 643 - 778 - 778 - 778)
matthewf
09-20-07 05:27
edited on: 09-20-07 06:24

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 - 131 - 131 - 131 - 218 - 218 - 218)
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 - 347 - 365 - 365 - 365 - 365 - 365)
matthewf
09-20-07 12:57
edited on: 09-20-07 13:08

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 - 776 - 810 - 810 - 945 - 945 - 945)
matthewf
09-20-07 13:05
edited on: 09-20-07 13:11

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 - 1201 - 1324 - 1324 - 1324 - 1324 - 1324)
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 - 469 - 475 - 475 - 562 - 562 - 562)
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 - 554 - 614 - 614 - 614 - 614 - 614)
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 - 303 - 309 - 309 - 309 - 309 - 309)
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 - 1080 - 1204 - 1204 - 1204 - 1204 - 1204)
wiz
09-25-07 22:41
edited on: 09-25-07 23:03

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 - 216 - 222 - 222 - 513 - 513 - 513)
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 - 284 - 284 - 284 - 284 - 284 - 284)
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 - 194 - 200 - 200 - 200 - 200 - 200)
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 - 93 - 137 - 137 - 137 - 137 - 137)
matthewf
01-22-08 06:40
edited on: 01-22-08 06:42

"fix begin"
Installer mantis bug:1780 fix:'MenuMorph-BetterMouseHandling.2.cs'.
"fix end"

 
(0011976 - 477 - 527 - 655 - 655 - 655 - 655)
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 - 560 - 620 - 620 - 620 - 620 - 620)
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 - 400 - 412 - 548 - 548 - 548 - 548)
matthewf
04-08-08 04:56
edited on: 04-08-08 05:43

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 - 225 - 269 - 269 - 269 - 269 - 269)
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 - 137 - 137 - 137 - 137 - 137 - 137)
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 - 127 - 127 - 127 - 127 - 127 - 127)
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 - 70 - 70 - 70 - 70 - 70 - 70)
GazzaGuru
04-09-08 12:31

I've filled in the gaps from version Pinesoft-Widgets-gvc.260 onwards.
 
(0012577 - 165 - 203 - 203 - 203 - 203 - 203)
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"
 

- Issue History
Date Modified Username Field Change
09-11-05 05:41 wiz New Issue
09-11-05 10:46 laza Note Added: 0002638
09-17-05 10:24 laza Priority normal => low
09-17-05 10:24 laza Severity major => tweak
09-17-05 10:24 laza Status new => acknowledged
01-19-06 10:10 acon Note Added: 0003552
01-19-06 15:38 laza Note Added: 0003554
01-20-06 07:33 wiz Note Added: 0003576
09-20-07 03:51 wiz Relationship added child of 0006635
09-20-07 03:52 wiz Relationship added related to 0006687
09-20-07 05:22 matthewf File Added: BringMenuToFrontHack.1.cs
09-20-07 05:27 matthewf Note Added: 0011167
09-20-07 05:31 matthewf Status acknowledged => assigned
09-20-07 05:31 matthewf Assigned To  => matthewf
09-20-07 06:23 matthewf Relationship added related to 0006690
09-20-07 06:24 matthewf Note Edited: 0011167
09-20-07 12:49 matthewf File Added: MenuMorph-BetterMouseHandling.1.cs
09-20-07 12:50 matthewf Note Added: 0011171
09-20-07 12:57 matthewf Note Added: 0011172
09-20-07 13:00 matthewf Note Edited: 0011172
09-20-07 13:01 matthewf Note Edited: 0011172
09-20-07 13:05 matthewf Note Added: 0011173
09-20-07 13:08 matthewf Note Edited: 0011172
09-20-07 13:11 matthewf Note Edited: 0011173
09-23-07 02:13 wiz Note Added: 0011179
09-23-07 03:09 matthewf Note Added: 0011180
09-25-07 05:44 wiz Note Added: 0011202
09-25-07 06:58 matthewf Note Added: 0011203
09-25-07 22:41 wiz Note Added: 0011208
09-25-07 23:03 wiz Note Edited: 0011208
09-25-07 23:28 wiz Relationship added parent of 0006699
09-25-07 23:36 matthewf Resolution open => fixed
10-09-07 23:15 matthewf Note Added: 0011277
10-09-07 23:16 matthewf File Added: MenuMorph-BetterMouseHandling.2.cs
10-09-07 23:17 matthewf Relationship added related to 0005608
10-09-07 23:25 matthewf Relationship replaced related to 0006699
10-09-07 23:25 matthewf Relationship added child of 0006530
10-09-07 23:29 matthewf Note Added: 0011278
11-24-07 15:00 matthewf Issue Monitored: matthewf
11-26-07 10:22 edgardec Note Added: 0011481
11-29-07 07:05 wiz Relationship added related to 0006791
01-22-08 06:40 matthewf Note Added: 0011699
01-22-08 06:41 matthewf Note Edited: 0011699
01-22-08 06:42 matthewf Note Edited: 0011699
04-08-08 00:39 kbrown Note Added: 0011976
04-08-08 04:36 matthewf Note Added: 0011979
04-08-08 04:56 matthewf Note Added: 0011980
04-08-08 05:29 matthewf Note Edited: 0011980
04-08-08 05:43 matthewf Note Edited: 0011980
04-08-08 05:51 matthewf Note Added: 0011981
04-08-08 22:31 GazzaGuru Note Added: 0011985
04-08-08 22:31 GazzaGuru Issue Monitored: GazzaGuru
04-09-08 00:12 matthewf Note Added: 0011986
04-09-08 12:31 GazzaGuru Note Added: 0011987
09-03-08 14:03 Keith_Hodges Note Added: 0012577
01-09-09 23:53 Keith_Hodges Status assigned => pending


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
224 total queries executed.
112 unique queries executed.
Powered by Mantis Bugtracker