GNU bug report logs - #745
pop-to-buffer, frames, and input focus

Previous Next

Full log

Message #140 received at 745 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 745 <at> debbugs.gnu.org
Subject: Re: bug#745: pop-to-buffer, frames, and input focus
Date: Sun, 31 Aug 2008 10:55:32 +0200

* martin rudalics [2008-08-30 15:42+0200] writes:

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

Sounds good.

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

Perhaps it means "newly mapped window".  I guess some window manager
could give the focus to a newly mapped window only if its timestamp is
newer than the timestamp of the currently focused window.  I would be
surprised though, if some application would rely on this behavior :-)
Continuously updating this timestamp, e.g. on every keypress, sounds
rather excessive just to give the WM this possibility.

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

Yes, I think the same.

Helmut.

>  LocalWords:  timestamp keypress

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.