STR #2799

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]

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
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 ]
Name/Time/Date Text top right image
#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

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 || 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).
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]


Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.