all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Daniel Colascione <dancol@dancol.org>
To: Po Lu <luangruo@yahoo.com>
Cc: 57012@debbugs.gnu.org
Subject: bug#57012: Activating versus raising frames
Date: Sat, 6 Aug 2022 22:07:23 -0400	[thread overview]
Message-ID: <06468240-fd7c-72e8-2538-b65dd2f28665@dancol.org> (raw)
In-Reply-To: <87y1w03jhv.fsf@yahoo.com>

On 8/6/22 21:55, Po Lu wrote:
> Daniel Colascione <dancol@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.






  reply	other threads:[~2022-08-07  2:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-06  0:54 bug#57012: Activating versus raising frames Daniel Colascione
2022-08-06  1:44 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-06 23:57   ` Daniel Colascione
2022-08-07  1:55     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-07  2:07       ` Daniel Colascione [this message]
2022-08-07  2:45         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-07  2:52           ` Daniel Colascione
2022-08-07  3:02             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-07  3:11               ` Daniel Colascione
2022-08-07  3:29                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-07  4:10                   ` Daniel Colascione
2022-08-07  4:29                     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-07  4:59                       ` Daniel Colascione
2022-08-07  5:27                         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-20 11:30                           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=06468240-fd7c-72e8-2538-b65dd2f28665@dancol.org \
    --to=dancol@dancol.org \
    --cc=57012@debbugs.gnu.org \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.