STR #1377

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.1 ]

STR #1377

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:2 - Low, e.g. a documentation error or undocumented side-effect
Scope:2 - Specific to an operating system
Summary:Window focus issues on OSX/non-modal windows.
Created By:wavexx
Assigned To:matt
Fix Version:1.1-current (SVN: v5333)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Name/Time/Date Filename/Size top right image
#1 wavexx
05:23 Aug 03, 2006
#2 wavexx
05:24 Aug 03, 2006
#3 wavexx
05:25 Aug 03, 2006
#4 wavexx
05:26 Aug 03, 2006
#5 wavexx
05:27 Aug 03, 2006
bottom left image   bottom right image

Trouble Report Comments:

Name/Time/Date Text top right image
#1 wavexx
07:54 Jul 28, 2006
There are some focus issues when more than one non-modal window is shown on OSX. Documentation states that the window returned by first_window will receive keyboard events, but this doesn't seem the case. Some FL_FOCUS debugging reveals that clicking on a different window or changing manually the window with first_window does not give the selected window any focus or events.

I have an application that uses non-modal windows as "floating tool windows" but the main windows needs to receive keyboard events when active. When one or more non-modal windows are shown, the main window loses its focus and does not get it back when the main window is clicked or selected through the title bar (the window correctly accepts FL_FOCUS/etc events).

I have managed to get back focus to the main window by clicking on it, clicking on a non-modal window, clicking again on the main window and pressing some keys(!). Notice that the main window correctly receives FL_PUSH/RELEASE events even when not focused.

Unfortunately I don't have time right now to produce a little trivial example (really easy to reproduce anyway) or debug it.
#2 wavexx
05:27 Aug 03, 2006
Ok, here's the test case.

run focusbug0: two standard windows. initially "standard 1" will have
focus. Clicking inside "standard 0" will correctly give it focus. Clicking
on the title bar works too. Switching to another app will remove focus from
both windows. The focused window correctly receive keyboard events.
(notice the FL_RELEASE bug I reported in another report when clicking on the
title bar or moving the window).

run focusbug1: a standard and a non modal window. Initially "non modal"
will have focus. Press a key: both windows receive an event (bug).
Restart, switch to another application, switch back by either clicking on
"non modal" title bar or by alt-tab: standard receives focus (bug).
Restart, click on "standard" either inside or the title bar, no focus (bug).
Restart, close "non modal", "standard" does not receive focus (bug).

The fix is to give non-modal windows both kFloatingWindowClass and
kWindowActivationScopeAll (converting the major kludge in a total hack[tm]).

I'd rise this to HIGH. See attached patch.
#3 wavexx
05:28 Aug 03, 2006
I'm sorry, I'm having trouble attaching files.

diff -ruw fltk-1.1.x-r5263.Orig/src/Fl_mac.cxx fltk-1.1.x-r5263/src/Fl_mac.cxx
--- fltk-1.1.x-r5263.Orig/src/Fl_mac.cxx        2006-07-21 18:29:46.000000000 +0200
+++ fltk-1.1.x-r5263/src/Fl_mac.cxx     2006-08-03 00:40:20.000000000 +0200
@@ -1832,6 +1832,7 @@
     if (w->non_modal() && !w->modal()) {
       // Major kludge: this is to have the regular look, but stay above the document windows
       SetWindowClass(x->xid, kFloatingWindowClass);
+      SetWindowActivationScope(x->xid, kWindowActivationScopeAll);
     if (!(w->flags() & Fl_Window::FL_FORCE_POSITION))
#4 matt
06:35 Aug 19, 2006
Fixed in Subversion repository.

Thanks for this suggestion. Sorry for the delay in actually implementing it.
bottom left image   bottom right image

Return to Bugs & Features ]


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