| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #2802
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | poor modality interaction with local window manager |
Version: | 1.3-current |
Created By: | ossman |
Assigned To: | ossman |
Fix Version: | 1.3-current (SVN: v10190) |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | ossman 03:33 Jan 25, 2012 |
| FLTK doesn't tell the local WM that a window is modal, which means that you lack the visual clues normally associated with it. It is possible to do better by interacting more with the local WM.
The attached patch does the following:
- Sets _NET_WM_STATE_MODAL on X11
- Redirects focus to the modal window on Win32
- Makes all other windows refuse to become key or main on OS X
This gives an improved behaviour on all platforms in that the window decorations will always indicate that the modal window has focus. IOW, FLTK and the local WM now agree on who has focus.
Issues remaining (and I don't intend to address those on this bug):
- X11: Windows are transient/modal for another window, not the entire window group (this is almost impossible to solve as there are sooo many bugs in the WMs in this area).
- Win32/OS X: The proper way of doing modal/non-modal windows involves releasing control of the main loop, so it isn't easily done in FLTK. We can only try to emulate the native behaviour.
- Win32: Proper behaviour is to blink or otherwise visually indicate that focus is modal. Right now it simply just refuses to change focus.
- OS X: Layering is off if you have multiple levels of modal/non-modal windows. | |
|
#2 | fabien 15:08 Apr 21, 2012 |
| If I add the following on OS X: - (BOOL)canBecomeKeyWindow { if (Fl::modal_ && (Fl::modal_ != w)) return NO; // prevent the caption to be redrawn as active on click // when another modal window is currently the key win
return !(w->tooltip_window() || w->menu_window()); }
I can now have my window caption staying disabled while another modal window has the focus, so it works fine.
Now what's the benefit of adding a canBecomeMainWindow as it seems to work fine with only the key window mod ? When I implement it as well I can see no change, did I miss something ? | |
|
#3 | ossman 00:27 Apr 23, 2012 |
| I'm afraid I've forgotten the details, but I believe it was necessary to get the correct window decoration. Without that code it would display multiple windows' title bars as "active". | |
|
#4 | fabien 17:23 Apr 23, 2012 |
| mmmm, as we now have a test for excluding tooltip and menu windows in canBecomeKeyWindow() ; it might explain why this does not seem to make any difference. | |
|
#5 | astrand 05:38 Jun 19, 2012 |
| Updated patch for latest 1.3.x trunk. Note that it reverts r9324 which was bad; it collides with for example the TigerVNC runtime popup window. | |
|
#6 | ossman 04:57 Jun 11, 2014 |
| You accidentally committed the OS X portions of this in r9406. :)
I'll do some cleanup and fix the other platforms. | |
|
#7 | ossman 07:10 Jun 11, 2014 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |