From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!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: Wed, 15 Jan 2020 09:08:19 +0100 Message-ID: <67eb5852-2047-1e74-1c83-fb8f1767a772@gmx.at> References: <2056a194.3971.16f8d4dd4c5.Coremail.tumashu@163.com> <7c344291-8161-eff1-b07b-fb764535abef@gmx.at> <877e0bd3-d21b-43a4-b5fa-c33f123a14c0@gmx.at> <9475f3ba-cfd5-c808-3647-2c395c1ee851@yandex.ru> <8f465e5f-fd61-9540-e094-31487eea60b4@gmx.at> <49dd7093-cd65-f50d-fca5-f1859fc8fdab@yandex.ru> <3b6682cc-b484-84e6-7b4d-0972f1d592b7@gmx.at> <0c6ffbc3-f2a0-9658-c23d-f2838e307163@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="103873"; mail-complaints-to="usenet@blaine.gmane.org" Cc: "emacs-devel@gnu.org" To: Dmitry Gutov , tumashu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 15 09:11:58 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1irdmK-000QUf-TT for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Jan 2020 09:11:53 +0100 Original-Received: from localhost ([::1]:50794 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irdmJ-0006Nr-3c for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Jan 2020 03:11:51 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43441) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irdjH-00053E-BR for emacs-devel@gnu.org; Wed, 15 Jan 2020 03:08:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1irdjD-00016t-DM for emacs-devel@gnu.org; Wed, 15 Jan 2020 03:08:43 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:60353) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1irdjD-00015H-0E for emacs-devel@gnu.org; Wed, 15 Jan 2020 03:08:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1579075701; bh=sTvQcagVzgqY5M/WrHnfzKaEqWhxf2uC20vADKkBWF0=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=D5VWELOKPJ6HTJiEZN5LXb7F5D4QjzVXpmtVgZeW7tauxsXeq+u3YtAEeep0CV8p6 X5e2glupT8KakxljAPV45Ux5V+AL7H/zC+Dw5xBDLrpxI5nEUCWk/KtScH1ZXsRObI hZjkP3Jv7Dizp4MuS4lQOKUOcEriU8IfhXTB8FyM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.86]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MacSe-1jNwbf21N4-00c89T; Wed, 15 Jan 2020 09:08:21 +0100 In-Reply-To: <0c6ffbc3-f2a0-9658-c23d-f2838e307163@yandex.ru> Content-Language: en-US X-Provags-ID: V03:K1:YZev5JkDH+ffxX1o/6gdZm6bkC9rjbk5Ae1onz8RK060HeHpnAl lmOv30Dc9lKaeih0NtpK23JIhYYNweeDH2yK8CSk4xk6IGRng760Wcpv4F4Lqp2EkMj+Xlz DzH9gtzKqlEaHCV27t5eyAiBWWME5yRNMyXCdvg1RjPfwYApQ30OBA79gvLTYEsONfAmKMF F4KNtu8BXY2oS/beICRyw== X-UI-Out-Filterresults: notjunk:1;V03:K0:yXE9GOAMyRE=:rSrMWavZyBBRm8mgr5IVNp 92HXVRhLarVcX7B1mqU2ZsC83Rwqw2bWFojSAm6TzzF3nbToqR8v2nrWRZsy+Ix2lBH4S88i4 rqxdzXgF0so1va42r/gJKJsO4+TBIDw+/v4B5Sl5jPDsVBLui5eZfT4IkbisOLzMr6/k1yRuQ uypq845CUDIOTCbl9C+dFl8iuVOVDDX6SOkbM83AiNJ5BBHCeNvUbZ+Gm6qKr4mIXCQWtQXIK Ce8Na2iutg28zKRSRjU3Ewwvybn1lq8RcwI1y3IC/xcRJSP1YQT9YDdEz5SbCqyUd5dXxeutG WIe+NpNvkgSV7H6YJ4SYI1924vQO4/4P/DYo8GOucXdYlJiMibI6UGEJou+SxLPdALUSBoF9n DdSCSQ47YShSm5svJB4YA3YKpnef8Dfr/slY0y/3CkMTMEPzVBQ+HMZWn35iw3uSTkRl79Pnr Mz+WRob8bs94R3uzhKmgdFIptnQYNILEZOu8s4vVH17vTyKq+fwRLKjS3J1XnEfFTQVfaMqGT 6cfGOoBNZkmSvJ21G4H4gm41qM1we1Fo11BY3dcowFwUKTBXDP4/7OpIKqXGniC0FFxxzl6RT 8NZhirW3EVWMjwTsBhaVW17fClIz1wawjDSLWVJLS2RfBnl4MLCX+vO1DVhHqXBKOnKJWplJh 6ha/zDZUGZJE5LWC1TXiZ+TVI3WjMj6juYmLs0h6iid469q03MmugLC+aHBW12I/dMBI3WrfJ 6XtkWiQnSXnZ72/Nn+9iUc0Izp/M3z6nRK6cHZTtevGoE5ztfnIf6bQJHEkmMSZI/7XCISZ+ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.15.18 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.org gmane.emacs.devel:244265 Archived-At: >> That's easy to check: Just create a new undecorated, non-child frame and >> see whether you can resize it. > > Any code I can try? (setq frame (make-frame '((undecorated . t)))) to make such a frame and for example (set-frame-size frame 40 40) to resize it. Try other values as well to verify. >> I doubt that at a position of 2037 much resizing can be done. In either >> case, the outer height of your child frame _has_ changed from 360 to 720 >> or at least 'frame-geometry' is told so. > > When I created it with the appropriate size, frame-geometry reflected it, yes. Sorry, I misread your message and thought the second 'frame-geometry' call reflected the frame's state after the failed resizing attempt. And I also thought that the outer position returned by 'frame-geometry' is relative to its parent. It isn't (correctly so). Only 'frame-position' returns the parent-relative value. >> Is yours by chance a >> high-resolution display? > > Yes, HiDPI. 3840x2160. And I also moved the window to the right side of the screen for convenience. So the numbers should be right, and there's certainly enough space for the child frame to be resized (it's much smaller than the parent frame). > >> >> - Can you reproduce Bug#38452? >> > >> > Yes. Every evaluation of the form in the first message shifts a simple, non-maximized frame a bit up-left by (24 . 22). >> >> Maybe that's the core of our problem. Either mutter doesn't want to >> put the frame where Emacs asks to put it or we don't understand where >> mutter has put it. > > But that other bug report is about positioning, isn't it? And this discussion is about resizing. Maybe it's the same issue and maybe the effect multiplies on HiDPI displays. Here (no HiDPI) I can use the following, slightly modified, version of tumashu's test case: (defun open-test (buffer) (display-buffer-in-child-frame buffer '((child-frame-parameters . ((width . 40) (height . 10) (top . 50) (left . 50) (drag-with-mode-line . t) ))))) (defun resize-test (frame) (set-frame-height frame 20)) (defun move-test (frame) (set-frame-position frame 0 0)) (setq-local test-buffer (get-buffer-create "*test child-frame*")) (setq-local test-frame (window-frame (open-test test-buffer))) (resize-test test-frame) ;(move-test test-frame) Does it move 'test-frame' when you evaluate the last (commented out) form? Can you move around 'test-frame' by mouse-dragging its mode line? martin