STR #2799: Menus can suddenly disappear - Fast Light Toolkit (FLTK)

STR #2799

Application:	FLTK Library
Status:	5 - New
Priority:	1 - Request for Enhancement, e.g. asking for a feature
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Core Library
Summary:	Menus can suddenly disappear
Version:	1.5-feature
Created By:	ajapted
Assigned To:	Unassigned
Fix Version:	Unassigned
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

Post File

No files

Trouble Report Comments:

Post Text

#1	ajapted 00:30 Jan 01, 2012

Clicking and releasing the mouse button should open a menu. However if the user drags the mouse a small distance before releasing the mouse button (but still staying on the menu button), the menu will appear briefly but disappear before the user can select anything on the menu, which is quite frustrating. This is under Linux, I haven't tested Windows. FLTK version 1.3.0 Cheers, -- Andrew Apted

#2	greg.ercolano 12:47 Jan 01, 2012

A little of my own research: notes for whomever takes this on. Starting from the top down, when someone clicks+releases in a menu, I think it works this way: 1) Clicking+release is handled by Fl_Menu.cxx's menuwindow::handle() 2) This calls menuwindow::early_hide_handle() 3) The switch() clause for FL_RELEASE uses "!Fl::event_is_click()" to determine if someone 'clicked and released' while moving the mouse in between. (When it comes to clicking buttons, a click+move+release is a way to "cancel" a button press) ..and Fl::event_is_click() (in Fl.H) returns e_is_click, whose value logic in X11 relevant here is I believe managed by set_event_xy()'s logic (in Fl_x.cxx, the X windows code), the relevant part I think being the '> 3' in the following code: ---- // turn off is_click if enough time or mouse movement has passed: if (abs(Fl::e_x_root-px)+abs(Fl::e_y_root-py) > 3 || fl_event_time >= ptime+1000) ---- ..which seems to allow for a "drag" of up to 3 pixels between the push and release. I believe the issue here is the logic for opening a menu uses the same logic as clicking a menu item, and arguably there should be different handling of click-drag-release for detecting the clicking of buttons & items (where a small distance change should 'cancel') vs. opening menus (where one should perhaps have to drag completely off the menu item to "cancel" it). If this is true, then perhaps the solution is to change early_hide_handle()'s unconditional use of Fl::event_is_clicked(), and have it use something else if opening a top-level menu. I'm not sure if Fl_Menu_Bar and Fl_Menu_Button use the same code for opening a menu, but that might be part of the issue, as perhaps the needs of one is not the need of the other; Fl_Menu_Button should probably act like a button (small mouse movement cancels menu), and Fl_Menu_Bar should probably not.

#3	matt 17:22 Apr 20, 2012

This is intended behavior, emulating pop-down and pull-down menus at the same time. The pop-down is clicked, pops up, then the user moves the mouse, clicks again to select an item. In the pull-down, the user pushed the mouse down on the menu, keeps the mouse pressed and dregs it to the menu that is to be selected. OS X for example works exactly the same way (MacOS OTOH had pulldown only menus, early MSWindows had pop downs).

#4	greg.ercolano 17:52 Apr 20, 2012

Answering on behalf of the OP, I think there is a valid issue to be solved. Our behavior is different than just about everything else, and it's a subtle thing.. probably something someone with a sensitive mouse would notice, such as a mouse that moves when the button is pushed (e.g. IBM thinkpads with those mouse 'pointer sticks' in the middle of the keyboard) Find an app with a File menu, and do these specific steps: 1) Click on the 'F' in a "File" menu 2) Drag a few *pixels* (from the 'F' to the 'i' in "File") without moving off the menu 3) Release In FLTK apps, the menu disappears, in all other apps, it stays open. This, due to a >1pixel movement between click/release. If a user likes "click-release stay-open" menus, they'll probably have a hard time getting them with something like a track-point mouse, or a mouse that moves easily during a press/release stroke.

#5	greg.ercolano 17:57 Apr 20, 2012

Or well, I should qualify that: On linux + windows the menus aren't 1pixel sensitive. On the mac, though, it seems they are just like FLTK; a micro-movement during click-release cancels the stay-open menus.

#6	fabien 17:58 Apr 20, 2012

Agreed as not a bug, work as designed: On OS X , if I click and drag even a little (even one pixel): it will close the main menu just like fltk does. BTW I like very much that feature as it is. Now closing, as we probably have enough valid bugs to focus on.

#7	greg.ercolano 20:01 Apr 20, 2012

But isn't it a bug on linux + windows?

#8	fabien 20:27 Apr 20, 2012

I would say no as fltk is supposed to work the same way all platforms in that regard. Now one could advocate it should work the same way on all platform with a tolerance, which I would not really like but would still respect. Feel free to re-open if it is the case, but then it should be an RFE severity not a MOD ...

#9	greg.ercolano 23:11 Apr 20, 2012

OK - I defer to the OP to weigh in, as I don't have a problem with the behavior myself.. my mouse doesn't move between push/release. As a last gasp on the subject, I can only recommend to the OP, he might be able to solve this if he changes the '3' in this line (mentioned above): // turn off is_click if enough time or mouse movement has passed: if (abs(Fl::e_x_root-px)+abs(Fl::e_y_root-py) > 3 || ..to something larger like 6. This will allow more mouse travel between push/release as not being mistaken as "movement".

#10	matt 01:47 Apr 21, 2012

That is actually a good point: with screen resolution getting higher and higher, 3 pixels may be a bad choice, causing this kind of problem. Maybe we should make this number depend on screen DPI?

#11	fabien 07:19 Apr 21, 2012

+1 for proportional instead of fixed detection, totally makes sense. I re-open this one a request for enhancement ...

#12	greg.ercolano 09:36 Apr 21, 2012

Not sure if the issue is "screen resolution" so much as it is "mouse resolution", or "how many 'mickeys' of mouse movement == noise". Probably exacerbated by various factors besides the hardware itself: mouse scaling/acceleration, fleshy fingers, long fingernails, etc. I would think those little keyboard 'stick' mice would be the worst offenders, possibly also those trackpads where you click on the pad itself. Both involve the 'button' also sensing X/Y movement, such that the mouse is more likely to move when pressing for a click. My mom encounters this problem with her new MacBook Pro; she has long fingernails, and so 'clicking' is an imprecise motion, where her fingers slide during clicking. Because of her nails, she 'pushes' at an angle instead of up/down, such that a click is more of a push-and-slide. It makes it hard for her to 'click' small buttons because the mouse always moves away while she's pressing.. drives her crazy.

#13	AlbrechtS 08:32 Feb 08, 2019

Moved from 1.3-feature to 1.4-feature. Re #10: "Maybe we should make this number depend on screen DPI?" This is at least partly resolved since we have HiDPI support with scaling in 1.4. Hence "mouse coordinates" which may be in screen resolution at the system level are scaled down to "FLTK coordinates" on high DPI screens if scaling is enabled (scaling factor > 1). This doesn't mean that the problem goes away though, but it might be mitigated at least. We could still create some kind of user preference that can be set in the program so we can change the "mouse drag tolerance" in the code cited by Greg (in comment #9).

#14	AlbrechtS 11:12 Apr 17, 2024

Bumped to 1.5-feature where we will likely design a new menu system.