STR #3377

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 | Roadmap 1.3 | Post Text | Post File | Prev | Next ]

STR #3377

Application:FLTK Library
Status:5 - New
Priority:3 - Moderate, e.g. unable to compile the software
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:Fl::grab() breaks event handling for some controls
Created By:dstarke
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
#1 dstarke
11:52 Apr 18, 2017
#2 dstarke
10:47 Apr 20, 2017
#3 dstarke
02:13 Apr 23, 2017
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
#1 dstarke
11:52 Apr 18, 2017
I tried to write a custom popup control but failed to do so due to various restrictions.
The main difference of a popup from a standard window is that it captures all events to see whether a click outside of it happened which forces it to close. This can currently (as far as I know) only be done with Fl::grab().
Widgets that check their focus state, however, fail from here on as we have an early out handling for the grabbing on state in fl_fix_focus() (see Fl.cxx), Fl::belowmouse() and Fl::focus().
Removing these early outs brings back focus to those widgets (like Fl_Input). Nevertheless, FL_KEYBOARD events are still not forwarded correctly. This is due to the navigation handling in Fl_Group::handle(), which usually works just fine because only the focused widget gets the events (including the FL_KEYBOARD event).
However, having grabbing enabled brings all events to the popup window, which currently needs to check which widget was focused to forward the events correctly.
The attached file shows the overall issue here (it works if the early outs are removed in Fl.cxx).
The following questions need to be answered to fix this problem properly IMHO:
1. Do we need the early outs when Fl::grab() is set in Fl.cxx?
2. Do we want Fl_Group to take over event delegation if needed?
3. Are there any shortcomings?
#2 AlbrechtS
09:10 Apr 20, 2017
Thanks for the report and the suggestions. I'm not sure though if discussion here is the right place and whether this should be considered a bug report or a request for enhancement (RFE).

Anyway: I compiled and ran your program and I can see differences, but I wonder what exactly you want to achieve. Could you please elaborate?

Fl::grab() is usually done for menu windows, and this needs all sorts of proper event handling - this includes closing the window when a user clicks outside the window as you described. Menu windows typically don't have input fields which makes things easier.

Maybe you could use a modal window that stays on top of its parent window as well and directs all event processing to this modal window but doesn't close if you click outside the window. All the FLTK standard dialogs (fl_ask, fl_choice, fl_input, fl_password, etc.) use such modal windows (and disable Fl::grab() while they are shown, BTW). A suitable way to dismiss such dialog windows is the Escape key.

I would also like to know what exactly you mean with "early out handling". Please specify the exact code lines, or even better, post a patch to this STR that shows how you removed "these early outs" which "brings back focus to those widgets (like Fl_Input)".

I don't know how to answer your questions (1-3) yet. Please provide more info, particularly what exact behavior you expect and what different behavior you see. This would make testing much easier. TIA.
#3 dstarke
11:01 Apr 20, 2017
If you only consider the available widgets it is probably just a request for enhancement.

I have attached a patch file. The "early outs" are removed by this. It also includes an out of focus patch for fl_show_colormap. I have left out changes in Fl_Group to leave that part open for discussion.
I have tested the changes on Windows 7 and Ubuntu 16.04 (Linux) without any issues.

Regarding whether such a feature offers any benefits:
The fl_show_colormap function already illustrates one of the advantages. You can design custom context sensitive popups without breaking the work flow too much. I have seen other applications with for more controls in their popups. So this is no new paradigm.
Often you want to break the work flow to signal something to the user, like with the provided standard dialogs. Sometimes you just want to adjust a value. In the later case modal dialogs add some additional burden to the user IMHO.

1. Proposed changes provided in the attached patch (grab.patch).
2. Not implemented/tested yet. See line 97-103 in attached custom_popup.cpp to get an idea.
3. I could not find any so far (Windows/Linux).
#4 dstarke
02:14 Apr 23, 2017
I have attached my proposed patch for this issue (grab2.patch).
This fixes controls like Fl_Input if grab() is enabled for their parent window.
This does not only apply to popups but also to other windows grabbed.
It also fixes the main window deactivation for fl_show_colormap().
I could not find any negative side effect due to this patch. Tested on Windows and Linux.

Please consider this patch for the next release.
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-2023 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.