GNU bug report logs -
#52666
27.0.50; Unexpected mode line flickering when creating frames
Previous Next
Reported by: Markus Triska <triska <at> metalevel.at>
Date: Sun, 19 Dec 2021 20:31:01 UTC
Severity: normal
Found in version 27.0.50
Done: Markus Triska <triska <at> metalevel.at>
Bug is archived. No further changes may be made.
Full log
Message #38 received at 52666 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> Are you sure that the new frame is _not_ selected when the mouse is _not_
> in that area?
Yes, the new frame is *not* selected in that case! I have constructed
the following test case to reproduce this:
(let ((f (make-frame `((parent-frame . ,(selected-frame))
(left . 200)
(width . (text-pixels . 200))
(height . (text-pixels . 200))
(top . 200)))))
(eq f (selected-frame)))
When I evaluate it, and the mouse is far away from the window, I get
"nil" as the result, showing that f is not the selected frame. I get
this with the Lucid build on OSX and Debian.
In fact, also if the mouse is within the area where the new frame
appears, I still get "nil", and the new frame is not selected: The
existing frame remains the selected frame, independent of the position
of the mouse.
I previously thought that the new frame is selected, but that was
apparently mistaken: It only appeared to be selected because when
entering text, the new (smaller) frame also shows the new text, even
though it is entered in the existing frame which is selected.
For my specific use case, this behaviour is ideal: I would like to show
information in a new frame, but not select the frame. I am surprised to
hear that in your configuration, the new frame is indeed selected. Do
you accordingly get t as the result of evaluating the above form?
Thank you and all the best,
Markus
This bug report was last modified 3 years and 149 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.