GNU bug report logs - #57012
Activating versus raising frames

Previous Next

Package: emacs;

Reported by: Daniel Colascione <dancol <at> dancol.org>

Date: Sat, 6 Aug 2022 00:55:02 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Daniel Colascione <dancol <at> dancol.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 57012 <at> debbugs.gnu.org
Subject: bug#57012: Activating versus raising frames
Date: Sat, 6 Aug 2022 22:07:23 -0400
On 8/6/22 21:55, Po Lu wrote:
> Daniel Colascione <dancol <at> dancol.org> writes:
>
>> Hoo boy. I spent a bit of time digging into the event code. The root
>> cause of the inability of emacsclient to raise the frame is that
>> we've been getting X11 event timestamps wrong for some time. In
>> particular, 1) in GTK builds, we're not updating the X timestamps for
>> keyboard and mouse input events
> The reason for that is because GTK is supposed to do that itself, after
> the event ends up dispatched to GDK.  I will investigate this further.

The GDK code specifically mentions that programs that handle events 
themselves (like Emacs) need to explicitly update the event time (as my 
patch does)

>> , and 2) we're not updating the X timestamp when we get an emacsclient
>> request.  Because of #2, when we call x-focus-window in
>> select-frame-set-input-focus, the timestamp we send along with the
>> _NET_ACTIVE_WINDOW request is stale, causing some window managers
>> (e.g. cinnamon and kwin) to just ignore the _NET_ACTIVE_WINDOW. But
>> because we use _NET_ACTIVE_WINDOW *and* XSetInputFocus and the latter
>> works, the overall effect is that the call to
>> select-frame-set-input-focus in server.el focuses the Emacs window,
>> but doesn't raise it.
> That sounds likely to me, thanks for investigating.
>
>> The following patch should fix both problems:
> Right, but I saw a similar problem in the DND code,

What is the bug?

> so I'd prefer you
> modified `x-display-set-last-user-time' instead.  I think adding a
> separate FRAME argument to that function would be in order.

We could do that, sure.

>   Aside from
> that, this is too X-specific to warrant a terminal hook.

Sorry, but I strongly disagree. The concept of signaling to the 
underlying window system that the user has interacted in some manner 
with a frame is generic and not X-specific. In fact --- doesn't the pgtk 
backend need an implementation of this hook too? It, like the 
conventional GTK backend, is blind to interactions with the frame 
performed using emacsclient.

> The rest of the code is fine by me (tho there is a
> dpyinfo->server_time_monotonic_p flag that can be used to avoid a sync
> with the X server when trying to obtain the server time),

I think server_time_monotonic_p is an unnecessary optimization.

> but needs coding style fixes. I'm sure you already know how to do that.

The style is fine, thanks.





This bug report was last modified 2 years and 241 days ago.

Previous Next


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