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

[Helmut Eller <eller.helmut@gmail.com>]

* martin rudalics [2008-08-28 23:26+0200] writes:

>> I know about the following problems:
>>
>>  1. pop-to-buffer doesn't switch input focus
>>  2. select-window doesn't switch input focus
>>  3. x-create-frame does switch input focus (with most WMs)
>>
>> Is there something else?
>
> The XSetInputFocus vs x_ewmh_activate_frame dichotomy in
> `x-focus-frame'.

Emacs could first test whether the window manager is EWMH compliant and
depending on the outcome only call one of those functions.
x_ewmh_activate_frame seems to test whether the WM supports
"_NET_ACTIVE_WINDOW".  I guess, we could just move that over to
x-focus-frame.

>> We agreed that we wont fix 3.
>
> Yes.

Over night I had a little idea that could be useful.  I'm just writing
it down here so that it's not lost: We could avoid the focus-when-mapped
problem, if we clear the input flag in WM_HINTS (the GTK equivalent
seems to be gtk_window_set_accept_focus) when we create the frame.  But
when we receive the MapNotify event, we enable the flag.  This should
prevent the window manager from focusing the frame initially but
afterwards it should be treated as usual.

I also found the gtk_window_set_focus_on_map function.  This seems to
rely on the _NET_WM_USER_TIME EWMH.  Sawfish ignores _NET_WM_USER_TIME,
but it could be useful for other window managers.

>> Fixing 2 isn't so clear.  This was shortly discussed on the mailing list
>> but RMS said, at that time, that more important things should be done.
>
> You mean we could solve this with your update-focus-lazily approach?

I think it's feasible, yes.

Helmut.