FLTK logo

STR #3201

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 | SVN ⇄ GIT | Prev | Next ]

STR #3201

Application:FLTK Library
Status:5 - New
Priority:2 - Low, e.g. a documentation error or undocumented side-effect
Scope:2 - Specific to an operating system
Subsystem:X11
Summary:unix Fl_Window::show _NET_ACTIVE_WINDOW event needed to raise
Version:1.3.3
Created By:mschwarzenberg
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size  
 
#1 mschwarzenberg
03:17 Feb 27, 2015
patch2.patch
1k
 
 
#2 mschwarzenberg
05:19 Mar 02, 2015
Fl_Window_showtest.cpp
3k
 
     

Trouble Report Comments:

Post Text ]
Name/Time/Date Text  
 
#1 mschwarzenberg
03:17 Feb 27, 2015
When Fl_Window::show() is used to raise another fltk window in the same application, modern unix window managers may not raise the window just by using XMapRaised.

See the attached patch.
 
 
#2 AlbrechtS
04:17 Feb 27, 2015
Thanks for the report and the patch.

Note: I changed priority to 2 (Low) because this is not an important feature for FLTK's operation.

Do you have any references of which "modern unix window managers" need this (and why)?

What I found so far is in "Extended Window Manager Hints" (latest = 1.5):

http://standards.freedesktop.org/wm-spec/latest/
http://standards.freedesktop.org/wm-spec/latest/ar01s03.html
http://standards.freedesktop.org/wm-spec/latest/ar01s03.html#idm139870830075168

The patch looks plausible[1], but I'd like to have an example to use for testing. Can you give example WM's that need this? Test scenario? Simple test program?

[1] I'd probably implement some details differently, but the patch looks good.
 
 
#3 mschwarzenberg
05:17 Mar 02, 2015
i must admit that the patch is already old, i've been using it for years. At that time i was using fvwm 2.4.something. The EWMH code was borrowed from wmctrl (https://sites.google.com/site/tstyblo//wmctrl/).

However the patch is still needed with the wm i can test here:

kwin (4.11.15): Window is not raised w/o the EWMH hint.
xfwm4 (4.10.1): Window is raised, but not focused w/o EWMH hint.

The reason for this may be "focus stealing prevention", which is configurable for most wm - if it's disabled, then Fl_Window::show() won't need the EWMH hint.

in the 2nd file attachment there is a small sample program, opening a window from which a second one can be openend. The windows can show() each other with the EWMH hint set (as in the patch) or without (current fltk behavior).  The attachment contains a slightly stripped down version of wmClientMsg().
 
 
#4 AlbrechtS
07:41 Mar 02, 2015
Thanks for the info, the link, and the demo program. This is very helpful.

I can add to your list:

Ubuntu 14.04, Unity (default setup): Window is raised, but not focused w/o EWMH hint.

I didn't check configuration options yet.

So far, so good. But ... you wrote:

> The reason for this may be "focus stealing prevention",
> which is configurable for most wm - if it's disabled,
> then Fl_Window::show() won't need the EWMH hint.

In other words: if we implemented your patch to utilize the EWMH hint, then we would effectively _disable_ "focus stealing prevention", which might not be what we want in the general case. This option exists for good reasons.

To resolve the issue I can see several options:

(1) add an option (another argument) to Fl_Window::show()

(2) add a global and/or user-specific FLTK configuration option;
    default OFF, but selectable to enable this "focus stealing" EWMH hint.

(3) implement another 'show' method (say: Fl_Window::show_and_focus()) or something like that so users (developers) can work around "focus stealing prevention" in specific cases where _they_ believe that this is sensible.

Comments, anybody? What do other devs think about this "focus stealing" option? How do other GUI toolkits handle this?
 
 
#5 chris
08:35 Mar 02, 2015
Maybe it's enough to use take_focus(). This makes focusing work in the non EWHM case at least on my Ubuntu 14.04:

--- show_test.cxx 2015-03-02 17:26:10.034764499 +0100
+++ show_test_new.cxx 2015-03-02 17:26:00.806764929 +0100
@@ -69,6 +69,8 @@
          wmClientMsg(fl_display, fl_xid_(this), "_NET_ACTIVE_WINDOW");
        } else {
          std::cout << " show std" << std::endl;
+         Fl_Window::take_focus();
+         std::cout << "and take_focus" << std::endl;
        }
        XMapRaised(fl_display, fl_xid_(this));
      }
 
 
#6 mschwarzenberg
01:23 Mar 03, 2015
regarding using take_focus:

works here with xfwm4 (4.10.1)
doesn't work with kwin (4.11.15) - window is not raised and not focused.

but actually, take_focus() should work, since it (conditionally) uses the EWMH hint: Fl::focus() -> Fl_X::activate_window(). The question is 
what happens in the kwin case where it seems to have no effect.

questions regarding the show() semantics:
* shall show() raise the window ?
* shall show() also give focus to the window ?

The documentation for Fl_Window::show() says:

If the window is already shown then it is restored and raised to the top. This is really convenient because your program can call show() at any time, even if the window is already up. It also means that show() serves the purpose of raise() in other toolkits.

So, according to this the window should be raised but not necessarily focused.

Note, focus stealing prevention may also mean raise prevention depending on the chosen focus policy (explicit, under mouse, focus means raise etc ...)

For me the issue was solved when take_focus() (to be called after show() - which must raise according to the documentation) would work reliably with an appropriate hint added to the documentation.
 
 
#7 AlbrechtS
03:39 Mar 03, 2015
@chris: Thanks for your hint about take_focus().

@Markus: Please try

  win->show();
  win->wait_for_expose();
  win->take_focus();

wait_for_expose() is available since FLTK 1.3.3 and was added due to a similar issue.

For further information please see the docs:
http://www.fltk.org/doc-1.3/classFl__Window.html#aafbec14ca8ff8abdaff77a35ebb23dd8
 
 
#8 mschwarzenberg
05:20 Mar 03, 2015
invoking wait_for_expose() doesn't help in the kwin case.

Maybe kwin ignores the Fl_X::activate_window() effort (called from take_focus()) since timestamp=0 in send_wm_event.

I still have to figure out what to do to get the correct timestamp. Any hints, anybody?
 
 
#9 chris
08:59 Mar 03, 2015
I read it, that the timestamp should be the last time delivered to that window in any event with time information.

e.g. ButtonPress/Release contain Time time (in milliseconds).

Several events have time information.

So that would mean to save this Time value per window and pass it to the _NET_ACTIVE call.
 
 
#10 chris
09:20 Mar 03, 2015
I wonder that your demo program might work with kwin too, because it uses 0 as source field.

Citing from the freedesktop docs Albrecht posted the links to in #2:

Source indication in requests

Some requests from Clients include type of the Client, for example the _NET_ACTIVE_WINDOW message. Currently the types can be 1 for normal applications, and 2 for pagers and other Clients that represent direct user actions (the Window Manager may decide to treat requests from applications differently than requests that are result of direct user actions). Clients that support only older version of this spec will have 0 as their source indication, thus not specifying their source at all. This also may mean that some of the fields in the message comply only with the older specification version.
 
 
#11 mschwarzenberg
23:27 Mar 03, 2015
i tested the kwin case with

a) event.xclient.data.l[0] = 0 -> "older version"
b) as in Fl_X::activate_window()
   (note: passing data.l[1] = 0 means actually CurrentTime,
    which sounds correct)

a) is always accepted in kwin.
b) is only accepted with "focus stealing prevention level" <= medium.

Having looked at other projects, most of them also use some equivalent  to b).

gtk however has (as suggested by chris in comment 9)
  gtk_window_present_with_time (gtk/gtkwindow.c)
which indeed uses the timestamp of the current event (if no explicit timestamp is given). See gtk_get_current_event_time (gtk/gtkmain.c),
gdk_event_get_time (gdk/gdkevents.c).
 
     

Return to Bugs & Features | Post Text | Post File ]

 
 

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'.