From: Robert Pluim <rpluim@gmail.com>
To: martin rudalics <rudalics@gmx.at>
Cc: Po Lu <luangruo@yahoo.com>,
74074@debbugs.gnu.org, Jimmy Yuen Ho Wong <wyuenho@gmail.com>
Subject: bug#74074: 30.0.92; [NS] Frame position not reported on resize from top left
Date: Wed, 06 Nov 2024 11:16:28 +0100 [thread overview]
Message-ID: <87ttckmzur.fsf@gmail.com> (raw)
In-Reply-To: <2efaf664-752f-4c82-9fbf-bc66ed90b366@gmx.at> (martin rudalics's message of "Wed, 6 Nov 2024 10:31:12 +0100")
>>>>> On Wed, 6 Nov 2024 10:31:12 +0100, martin rudalics <rudalics@gmx.at> said:
>> I see that under X11, the `move-frame-functions' are called when
>> resizing from the top left. I donʼt know what happens on MSWindows or
>> in a pgtk build.
martin> It works on MSWindows here. IIRC pgtk doesn't care abut positions at
martin> all.
pgtk doesnʼt let you programatically change the frame positions, but
Iʼm assuming it still reports them <time passes> Hmm, no, it
doesnʼt. I donʼt know if thatʼs expected or not. Po Lu?
(in fact, (frame-position) always reports the same values, whatever I
do to the frame. Yet another reason to avoid the pgtk build)
>> A quick experiment shows that itʼs fixable on macOS, although there is
>> a (strong) tendency for the 'moveʼ events to get bunched up until
>> after the resize ends, which means they all report the same
>> position. But then again this happens to a lesser extent under X as
>> well.
martin> I'm not sure I understand: Under X11 we "bunch up" all ConfigureNotify
martin> events for one and the same window. If a user resizes a window by
martin> dragging its top/left corner, they should all report different
martin> positions.
On macOS the 'move' events all arrive at once after the resize finishes, and
they all report the final size of the frame. Of course that may be due
to my implementation (the window size changes are reported as they
happen, but they follow a different code path).
>> The question is: do we *want* to fix this?
martin> Probably in a uniform way for all platforms (sans pgtk).
OK
Robert
--
next prev parent reply other threads:[~2024-11-06 10:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-28 23:36 bug#74074: 30.0.92; [NS] Frame position not reported on resize from top left Jimmy Yuen Ho Wong
2024-11-06 8:29 ` Robert Pluim
2024-11-06 9:31 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-06 10:16 ` Robert Pluim [this message]
2024-11-06 12:52 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-06 12:58 ` Eli Zaretskii
2024-11-06 13:50 ` Robert Pluim
2024-11-06 13:59 ` Jimmy Wong
2024-11-06 14:36 ` Eli Zaretskii
2024-11-07 8:34 ` Robert Pluim
2024-11-07 18:26 ` Jimmy Wong
2024-11-07 20:13 ` Robert Pluim
2024-11-08 12:26 ` Jimmy Wong
2024-11-08 13:37 ` Robert Pluim
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ttckmzur.fsf@gmail.com \
--to=rpluim@gmail.com \
--cc=74074@debbugs.gnu.org \
--cc=luangruo@yahoo.com \
--cc=rudalics@gmx.at \
--cc=wyuenho@gmail.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).