GNU bug report logs -
#745
pop-to-buffer, frames, and input focus
Previous Next
Full log
View this message in rfc822 format
* 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.
This bug report was last modified 16 years and 254 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.