bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event record


From: martin rudalics
Subject: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window
Date: Thu, 12 Oct 2017 10:05:52 +0200

> So if I have 2 frames, f1 and f2, and a Chrome web browser window that is
> atop f2, then if I drag from f1 into Chrome above f2, my drag release code
> reports that the release window is in f2 rather than nil, as it should be.
> I am on macOS which uses click to focus, so Emacs still gets the release
> event since Chrome has not been selected with a click.

I would call this a feature: f2 is probably the one meaningful target of
your operation at that screen position.

> Is there any way to deal with external window z-order layering such that
> one can tell within Emacs whether the topmost OS-level window at an
> absolute mouse position is an Emacs frame or not?

Not really.  Compositing window managers on X no more allow to track the
visibility of windows reliably.  So while we can discern the visibility
of our own (window manager) windows based on what we store in their
asscociated frames' 'visible' slots, we can't do that for windows of
other applications.  And processing whatever else XGetWindowAttributes
returns for another application's window might not be trivial either.

It should be possible to do what you want on Windows (where the debugger
also notifies you when an Emacs frame is obscured) though.

martin





reply via email to

[Prev in Thread] Current Thread [Next in Thread]