From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?=E9=99=88=E5=AE=87=E8=BF=AA?= Newsgroups: gmane.emacs.bugs Subject: bug#65183: 29.1; Child frame moving and resizing problems Date: Fri, 11 Aug 2023 17:09:29 +0100 Message-ID: References: <837cq3jmyk.fsf@gnu.org> <13c2f66e-861d-2ab3-6405-a2b57b29863b@gmx.at> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009d1e7a0602a7f046" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15876"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , 65183@debbugs.gnu.org, Eli Zaretskii To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 11 18:55:22 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qUVQ1-0003uR-Hi for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 11 Aug 2023 18:55:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qUVPm-0006z1-NR; Fri, 11 Aug 2023 12:55:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUVPk-0006xX-5I for bug-gnu-emacs@gnu.org; Fri, 11 Aug 2023 12:55:04 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qUVPi-00020K-Os for bug-gnu-emacs@gnu.org; Fri, 11 Aug 2023 12:55:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qUVPi-0004tK-Be for bug-gnu-emacs@gnu.org; Fri, 11 Aug 2023 12:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?=E9=99=88=E5=AE=87=E8=BF=AA?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Aug 2023 16:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65183 X-GNU-PR-Package: emacs Original-Received: via spool by 65183-submit@debbugs.gnu.org id=B65183.169177288418769 (code B ref 65183); Fri, 11 Aug 2023 16:55:02 +0000 Original-Received: (at 65183) by debbugs.gnu.org; 11 Aug 2023 16:54:44 +0000 Original-Received: from localhost ([127.0.0.1]:47882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUVPN-0004sc-8m for submit@debbugs.gnu.org; Fri, 11 Aug 2023 12:54:44 -0400 Original-Received: from mail-oi1-x233.google.com ([2607:f8b0:4864:20::233]:42022) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUUht-0003jU-Hv for 65183@debbugs.gnu.org; Fri, 11 Aug 2023 12:09:49 -0400 Original-Received: by mail-oi1-x233.google.com with SMTP id 5614622812f47-3a5a7e7cd61so1397180b6e.0 for <65183@debbugs.gnu.org>; Fri, 11 Aug 2023 09:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691770180; x=1692374980; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CWr2wlFvJ4ud9jKx5N8ndC9QYOOn18mHl1a/B90d3T4=; b=n8Qc3VVhSel9wNSrq+0qukbSW1wKI0rajZggCTxeL0ULk74OctfDtrNDsSZo4AvdDL om23Es1RIxjuobWmVUvjUXGbaTjVp8/OPnLJkMp/C1usvUy9RcfJ6eO0Z/VFEYNKOAc5 FzOF9F5vE5Z+dNHoKBJJRuSUEP8y/UX4XHQgaFQMCq8LG6D+Vw3OSSMS15ZClLqLVzKg 0U9hye2o92ls8XudPK94L+TOPFLjxWQ83AJ67xjPp2l9JEDbUJw55ax6pTMC3N4l2d/l vUwD/1uQXUalQQ0z8lEsP0W7XFseBRjCDFjP81s6O555QU/7RAZHuGmt27z0UaWqjXeo qPow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691770180; x=1692374980; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CWr2wlFvJ4ud9jKx5N8ndC9QYOOn18mHl1a/B90d3T4=; b=ZzAyRKWtjc7xwQJyHpSKk+YCNr8c4EQBQ5aAM78TlRq4a2tpiGMbpJRtdW38LXBK+m DuEFHTBHXk2oFhbKElfzO/zagzFCtCFm04+QOP1n1uHn/+wfo8wh/r7V50Xr65K9qTPG v/XNITp8ggLl0+4I+og9zUtWDzj08H7aj3r2xmLreuBi1S8N7QZfRo1Q0A22JTodlPJY F8AnJOuAt4D4ZgUFLLs3TfscqUl2XonpZR5xTqz6ov4i33ucprJCOMbRx4RyvNjH8IGz Z0Tf1S7WIOrWS473G/920ntC+FnmD9gjhMxuBhC79xbU1yqdO8U2+cMtLGeGqIwPbRo7 eOqg== X-Gm-Message-State: AOJu0Yya+JUthC9kjyaLtur6dmjSXPIZd4UfPTHeuLUbu6RdxXAsLPw+ 6+2wlckqYz70J9CtPLw1x422P8vidI8iLGCdnN8= X-Google-Smtp-Source: AGHT+IFCikH4/ujIZIC/EJ90VYcLnNAXuWha+H9/z6stZzNUR3FMKsIZ8uMBebHxX7+nypHcTeMs15XbwCyCuKsOA4I= X-Received: by 2002:a05:6808:1304:b0:3a1:db91:c5ef with SMTP id y4-20020a056808130400b003a1db91c5efmr3446805oiv.23.1691770179884; Fri, 11 Aug 2023 09:09:39 -0700 (PDT) In-Reply-To: X-Mailman-Approved-At: Fri, 11 Aug 2023 12:54:40 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:267222 Archived-At: --0000000000009d1e7a0602a7f046 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I tried `(setq x-wait-for-event-timeout 0)' and ran the test function. It was the same. By the way, I noticed that (though I believe you have read it), the GTK doc says "(gdk_window_move_resize) avoids strange visual effects. i.e. the user may be able to see the window first move, then resize, if you don=E2=80=99t use gdk_window_move_resize().". That is exactly what I= saw. martin rudalics =E4=BA=8E2023=E5=B9=B48=E6=9C=8811=E6=97= =A5=E5=91=A8=E4=BA=94 11:00=E5=86=99=E9=81=93=EF=BC=9A > > It seems that variables `x-gtk-resize-child-frames' and > > `x-gtk-use-window-move' do not help with this. > > As expected. > > > I am using KDE with KWin (X11) version 5.27.7. I don't know where ther= e > is > > any known issue on this platform. > > AFAICT KDE does not have any such problems. > > >>From another perspective, is there a way to perform resize and move at > the > > same time? > > We could try gdk_window_move_resize but we'd have to (1) investigate > whether it works well for child frames and (2) what to do on non-GTK > platforms. > > > (I mean, could the two steps be executed within a single redisplay > cycle, > > so that users would not see the intermediate changes?) > > If these two steps are not done separately, the execution order would > not > > matter. > > As I wrote in my first email, I can see the child frame being moved an= d > > then resized > > on my computer, even though the two steps happen very quickly. > > What happens when you change 'x-wait-for-event-timeout' to zero? > > martin > --0000000000009d1e7a0602a7f046 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I tried `(setq x-wait-for-event-timeout 0)' and r= an the test function.
It was the same.

B= y the way, I noticed that (though I believe you have read it),
th= e GTK doc says "(gdk_window_move_resize) avoids strange visual effects.
i.e. the user may be able to see the window first move, then resize,=C2=A0
if you don=E2=80=99t use=C2=A0gdk_window= _move_resize().". That is exactly what I saw.

martin rudalics <= ;rudalics@gmx.at> =E4=BA=8E2023= =E5=B9=B48=E6=9C=8811=E6=97=A5=E5=91=A8=E4=BA=94 11:00=E5=86=99=E9=81=93=EF= =BC=9A
=C2=A0>= ; It seems that variables `x-gtk-resize-child-frames' and
=C2=A0> `x-gtk-use-window-move' do not help with this.

As expected.

=C2=A0> I am using KDE with KWin (X11) version 5.27.7. I don't know = where there is
=C2=A0> any known issue on this platform.

AFAICT KDE does not have any such problems.

=C2=A0>>From another perspective, is there a way to perform resize an= d move at the
=C2=A0> same time?

We could try gdk_window_move_resize but we'd have to (1) investigate whether it works well for child frames and (2) what to do on non-GTK
platforms.

=C2=A0> (I mean, could the two steps be executed within a single redispl= ay cycle,
=C2=A0> so that users would not see the intermediate changes?)
=C2=A0> If these two steps are not done separately, the execution order = would not
=C2=A0> matter.
=C2=A0> As I wrote in my first email, I can see the child frame being mo= ved and
=C2=A0> then resized
=C2=A0> on my computer, even though the two steps happen very quickly.
What happens when you change 'x-wait-for-event-timeout' to zero?
martin
--0000000000009d1e7a0602a7f046--