From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Emacs's set-frame-size can not work well with gnome-shell? Date: Sun, 26 Jan 2020 18:38:48 +0100 Message-ID: References: <2056a194.3971.16f8d4dd4c5.Coremail.tumashu@163.com> <437eae9b-ccc1-3875-86b7-1af0e61b6e15@gmx.at> <710da57c-28dc-fab7-81af-0318a9389d6a@yandex.ru> <0e41cd9e-8be3-f67a-6958-7bad38ee1266@gmx.at> <6c86c25b-22df-2b69-34fe-539605f624ba@yandex.ru> <7dd69fe5-4ef4-782c-2fba-031d475f6406@yandex.ru> <32fb4915-be55-f753-5f6c-423a09030fd6@gmx.at> <8b252ea4-5902-d21e-a0d7-cdb3ddbb4e08@yandex.ru> <39d47d8c.4bad.16fcd672191.Coremail.tumashu@163.com> <729d39eb-d0b4-2cc5-cac3-e129a3effa87@yandex.ru> <06c6b6fb-ce6f-456b-6a22-c5a26a0ab297@gmx.at> <50912835-37d2-f15b-8fd1-b6619893d1ce@yandex.ru> <4a424bf3-ee08-b114-73ef-287bde14003b@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="78098"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" To: Dmitry Gutov , tumashu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 26 18:41:45 2020 Return-path: Envelope-to: ged-emacs-devel@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 1ivlur-000KHA-Hu for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Jan 2020 18:41:45 +0100 Original-Received: from localhost ([::1]:35752 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ivluq-00050v-G5 for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Jan 2020 12:41:44 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46022) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ivlsE-0004RY-SR for emacs-devel@gnu.org; Sun, 26 Jan 2020 12:39:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ivlsD-0000Nd-B1 for emacs-devel@gnu.org; Sun, 26 Jan 2020 12:39:02 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:55591) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ivlsC-0000Lu-Tf for emacs-devel@gnu.org; Sun, 26 Jan 2020 12:39:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1580060330; bh=a0utyQzB9vv5hEB01obfHb98ylBsmySorXmeDZ3Sjj8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Zxq6MNS/PxGDK51RNvjDheRs7zztt9JqrV/80C9adYhlX11BQTqwcTQlZ1d7kQzPH yMD12Rx2ZsEr7ATc4/+DjFbhgdhi/+yV6evHWKBRyQfI41r9jOQIXXKtNyVdcO1cx0 Qd4FuGtu/DMUtePAgPXBbdyMKUi2bzF6qa6/JQCs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.152]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MXGvG-1j6Bk42Pfy-00YgFD; Sun, 26 Jan 2020 18:38:50 +0100 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:jgMgXYumvVsrb46MJYZCC49hmdN3flzHNn6rKDyghMR+oWw11SQ KRj9FgxGPTj4YOrek5TRzAUQYkZYM6POQnZ3+H4n101X3CYpmWnBiUUA+0gHPy2t94Wm824 ADeja1swgQAYV8/xy/bzQMqeQpQCOObDyr33ewgMp43wDq5gzidXMEK/R9wDvP9UDHTY4N5 hlQ5bqEJJGuY6ITZhSCdA== X-UI-Out-Filterresults: notjunk:1;V03:K0:PS8PapVPKxY=:wiReIhEcwa46gL6VRCFPKl z1Of1OJI0HNQwWw8FAv5P8dLNnN+YdQ/VrypA3VTS/sgidgE0PeKn38/GEa0DI2wPCjLnG7Sm QumrF2xA9+z9qR4SAcySQ/ghRxhxCAy8SrLy2Ok2VozShPEAV39GBvVP5PXWXLq5avYHsUQDH e7Q+kHz47buvYL7Ec0HE6E7sVx7vz/qrj+Yf0/FdOMO+m8DQqgUSFlLcBCGXzYrZkvYpf8f+O Yv7Ysv6MSGelygJB192Y9LT1PhKPtFUdBhIjxyzfk5ZSgA3WHHFbueDXvcIQvSsM4/vBXlz/A vKXd8LUKJ31dZegPtZx7QubOqI3Fx4elnz77+QVrR+dtMpRg8FtGdZ3XctjJRlPOYhJMX0jKs QnQ6a2i7RWPAeYEt6F5/W99e0/GZ6RsmeYHpi3MJVPvFnUdUy4+1Lh9ne6C8o9Z3nga95DZKa 2SJAcwknYP0p9YrIlwtyG+4e97it7r4oCbEGMR2eVsum18VtgCh3WbagZHP1S2u8dZ4KrT8SV NAuZPpJ35jOkbVXTwC64VjlrmfZatDgkjBQaw9K6n33Ms7Tk9bqxDAc0j4xn6Uy8/YCu73Udl ESOjS+lLLNejIsc6uY+L/wq84NDawZOKP8Xxu0frX1f6CQIMoLPyCYgykBKs68Ci0DZArXzmp MFCnv0oZkIto3FTxZ/D/pEZTelomFgt9p1otGRQLqbp4PCZRmYI/qZbZRX69zG2e5YQPLhYZq DXlmiueit6BionbYn3Ysuo/IBSp7HPEXxBelEHkmx5TIG/7iVWs/MufvuoDBgMzk9rclm3qJ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:244661 Archived-At: >> > The first experiment: moving the frame by mode-line is smooth. >> >> And it's slow with child frames so we have a major difference here. >> Correct? > > It's a very murky story. > > I rebuilt with toolkit=lucid, tried the experiment > > => dragging by mode-line was choppy > > Changed the scaling factor of the desktop to 100% (everything became tiny on my monitor), restarted Emacs. > > => dragging by mode-line was smooth Don't you have some old laptop somwehere where you could try the experiments without scaling (I'd never believe that changing scaling on-the-fly works always in a reproducible fashion). And, it does _not_ work smoothly here. I can drag the frame smoothly by a short distance, then it suddenly jumps, then it drags smoothly again and so on ... > BUT dragging the borders to resize had the same problem I reported previously, so it's likely not HiDPI related. Dragging the right and bottom borders too? Here dragging any border is usually smooth with very occasional jumps. But it's much better than moving. I can only conclude that someone, somewhere simply drops an entire sequence of move requests. > Then I changed scaling back to 200%, restarted Emacs. > > => dragging by mode-line was still smooth (normal frame). That's what I meant with never to change scaling with a running desktop. Hot-plugging a scale factor is troublesome like changing the resolution of the display IMHO. > Then tried the child-frame example. > > => dragging was choppy. But it resizes smoothly enough when dragged > by the bottom or right edges. And, more importantly, resizes > correctly. When dragged by top-left, it resizes choppily, but still > correctly. > > In the same session, I applied your default-frame-alist change and > created a second "normal" frame. Dragging it by mode-line was choppy > again. This again hints at something not really reproducible when changing the scale factor. > And resizing it was broken in the same sense I described before > (and will again clarify below). > So, in the same session, a child frame and a normal frame have a > different resizing behavior. A normal frame can move smoothly > *sometimes*, a child frame always moves choppily. To a certain degree I see the same here. Just that resizing a normal frame is always smooth here. > When I drag top-left, the bottom-right corner seems to exhibit a more > gradual drift top-left. When I drag bottom-right, I moves top-left a > lot more quickly (even if I drag it in the bottom-right direction). This might be related to the fact that we move and resize in two distinct steps. I wrote a function to do both in one step but its behavior is just broken with pure X-builds and I'm not able to find out what goes wrong (it doesn't work with normal frames either). But it obviously might be a by-product of Bug#38452. > Please note: in most of my experiments I dragged by the corner > (top-left or bottom-right), and moved in circular-ish, random > trajectories. This triggers the bug most prominently. But if I just > grab one border and move the mouse in a straight line, that makes the > border move in the desired direction, albeit not exactly following the > mouse cursor (hence the effect, probably). > > E.g. if I drag the right border right, it moves after the mouse, but > more slowly than the mouse. If I move it left, it moves *faster* than > the mouse. Same with the bottom border. Top and left seem to have a > similar effect, but less pronounced. Also dragging the top border > seems to have an effect on the position of the bottom edge (it moves > up). In all cases, resizing is not smooth. Both of these hint at Bug#38452. > Seems so. Aside from the toolbar icons which are not scaled. The context menu appears where it should. Aha. Are tooltips well-positioned too? (A side question: Do emacs' native tooltips work with a gtk build - customizing 'x-gtk-use-system-tooltips' to nil?) > Also, the GTK3 build seems to have the same problem, and it has had quite a few HiDPI patches applied recently. You mean the icons problem? > So maybe scaling is not the actual issue (or the jumps would be sharper, this just occurred to me). > >> > In the meantime, resizing the first, "normal" frame works okay. Moving >> > too (by the title bar). >> >> How comes the first frame has a title bar with this specification > > Err, it never occurred to me to put this form in the init script. > > I launch Emacs, then evaluate this in scratch in the first frame, and then press 'C-x 5 2' and experiment with the second frame. > >> (setq default-frame-alist >> '((minibuffer . nil) (undecorated . t) (drag-with-mode-line . t) >> (border-width . 0) (internal-border-width . 8) (drag-internal-border . t) >> (menu-bar-lines . 0) (tool-bar-lines . 0))) >> >> > GTK: >> > >> > Actually, similar story with resizing. >> >> You mean similar to the Lucid resizing behavior? > > Yes (!!). Very similar (maybe exactly the same even). I just noticed that dragging the left border of a normal GTK frame moves the right border too here. So something is rotten. martin