[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#745: pop-to-buffer, frames, and input focus
From: |
Helmut Eller |
Subject: |
bug#745: pop-to-buffer, frames, and input focus |
Date: |
Sun, 31 Aug 2008 10:55:32 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
* 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
- bug#745: pop-to-buffer, frames, and input focus, (continued)
- bug#745: pop-to-buffer, frames, and input focus, Helmut Eller, 2008/08/27
- bug#745: pop-to-buffer, frames, and input focus, martin rudalics, 2008/08/28
- bug#745: pop-to-buffer, frames, and input focus, Helmut Eller, 2008/08/28
- bug#745: pop-to-buffer, frames, and input focus, martin rudalics, 2008/08/28
- bug#745: pop-to-buffer, frames, and input focus, Helmut Eller, 2008/08/29
- bug#745: pop-to-buffer, frames, and input focus, martin rudalics, 2008/08/29
- bug#745: pop-to-buffer, frames, and input focus, Helmut Eller, 2008/08/29
- bug#745: pop-to-buffer, frames, and input focus, martin rudalics, 2008/08/30
- bug#745: pop-to-buffer, frames, and input focus, Helmut Eller, 2008/08/30
- bug#745: pop-to-buffer, frames, and input focus, martin rudalics, 2008/08/30
- bug#745: pop-to-buffer, frames, and input focus,
Helmut Eller <=
- bug#745: pop-to-buffer, frames, and input focus, David Reitter, 2008/08/20