bug#745: pop-to-buffer, frames, and input focus

[martin rudalics <rudalics@gmx.at>]

 >> (1) do a `display-buffer' making a new frame without that frame getting
 >> raised and/or input focus, and
 >
 > If I call gtk_window_set_focus_on_map (GTK_WINDOW (wtop), FALSE) in
 > gtkutil.c:xg_create_frame_widgets, then Metacity dosn't give the focus
 > to new frames.  The initial Emacs frame is also not focused.
 > gtk_window_set_focus_on_map sets _NET_WM_USER_TIME to 0.  I know that
 > because I read the GTK source.  It can be verified by calling xprop on
 > the resulting Emacs frame.

In this case we'd have to make `pop-to-buffer' give focus to the frame,
look out for applications that ("wrongly") expect `display-buffer' to
focus the frame, focus the initial frame, and decide what to do about
`select-window/frame'.  After the release we could implement this for
all ewmh-compliant window-managers.

 >> (2) give input focus to/raise a frame that hasn't input focus/is not
 >> raised.
 >>
 >> entirely using _NET_WM_USER_TIME?
 >
 > I don't know how to that with _NET_WM_USER_TIME.

For _NET_WM_USER_TIME I read

    This property allows a Window Manager to alter the focus, stacking,
    and/or placement behavior of windows when they are mapped depending
    on whether the new window was created by a user action or is a
    "pop-up" window activated by a timer or some other event.

but I fail to understand what "new window" means here.

 > But the EWMH-spec says this:
 >
 >    _NET_ACTIVE_WINDOW, WINDOW/32
 >
 >    The window ID of the currently active window or None if no window has
 >    the focus. This is a read-only property set by the Window Manager. If
 >    a Client wants to activate another window, it MUST send a
 >    _NET_ACTIVE_WINDOW client message to the root window:
 >
 >    _NET_ACTIVE_WINDOW
 >      window  = window to activate
 >      message_type = _NET_ACTIVE_WINDOW
 >      format = 32
 >      data.l[0] = source indication
 >      data.l[1] = timestamp
 >      data.l[2] = requestor's currently active window, 0 if none
 >      other data.l[] elements = 0
 >
 >    Source indication should be 1 when the request comes from an
 >    application, and 2 when it comes from a pager. Clients using older
 >    version of this spec use 0 as source indication, see the section called
 >    "Source indication in request" for details. The timestamp is Client's
 >    last user activity timestamp (see _NET_WM_USER_TIME) at the time of the
 >    request, and the currently active window is the Client's active toplevel
 >    window, if any (the Window Manager may be e.g. more likely to obey the
 >    request if it will mean transferring focus from one active window to
 >    another).
 >
 >    Depending on the information provided with the message, the Window
 >    Manager may decide to refuse the request (either completely ignore it,
 >    or e.g. use _NET_WM_STATE_DEMANDS_ATTENTION).
 >
 > The current implementation of x_ewmh_activate_frame seems to work fine.

OK.

 >> I faintly recall a discussion about a
 >> misinterpretation of timestamps sent to the window-manager (Metacity?)
 >> by Emacs.
 >
 > I've seen Metacity spit out warnings along the lines that XSetInputFocus
 > was called with a wrong timestamp.  But I can't reproduce that right now.

Ahh, I recall that discussion.  Yet another reason why XSetInputFocus
should be avoided for ewmh-compliant window managers.  We should avoid
calling XSetInputFocus for these in the present release.

So I think we can distinguish three types of window managers according
to our needs and what _NET_SUPPORTS tells us:

- _NET_WM_USER_TIME capable ones, where we can have `display-buffer' not
   set the input focus for new frames (and thus not implicitly select the
   new window thus contradicting the doc-string of `display-buffer').  I
   suppose Metacity falls into this group.

- _NET_ACTIVE_WINDOW capable ones, where `display-buffer' will behave as
   now but x_ewmh_activate_frame works.  Sawfish seems to belong here.

- Non-ewmh-compliant ones where we have to use XSetInputFocus.

martin