FLTK logo

STR #2802

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 | 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:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 ossman
03:33 Jan 25, 2012
fltk-1.3.0-modal.patch
3k
 
 
#2 astrand
05:36 Jun 19, 2012
fltk-1_v2.3.0-modal.patch
2k
 
     

Trouble Report Comments:


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

 
 

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 'erco@seriss.com'.