| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
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 |
|---|
| Subsystem: | MacOS |
|---|
| Summary: | Window focus issues on OSX/non-modal windows. |
|---|
| Version: | 1.1-current |
|---|
| Created By: | wavexx |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | 1.1-current (SVN: v5333) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #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. | |
[ Return to Bugs & Features ]
|
| |
