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: Thu, 16 Jan 2020 19:33:31 +0100 Message-ID: <53c7798d-3022-d4bd-af56-ea4a5181a887@gmx.at> References: <2056a194.3971.16f8d4dd4c5.Coremail.tumashu@163.com> <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> <67eb5852-2047-1e74-1c83-fb8f1767a772@gmx.at> <9157f42c-ae6b-9537-4b44-08672cf60884@gmx.at> <4fc23d82-7a6a-6011-698a-b4f9d7eb6a53@yandex.ru> <5597826b-98b3-179d-ba9a-2deb314cba44@gmx.at> <2d112f1b-ea8e-ac49-1dac-9218db32f6fc@yandex.ru> <44dfe3ee-5c08-9a60-a642-8411c8e22921@yandex.ru> <35329f93-d7a9-e845-ddb4-9c4edec5fb43@yandex.ru> 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="87871"; 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 Thu Jan 16 19:36:56 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 1isA0m-000MgS-AD for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Jan 2020 19:36:56 +0100 Original-Received: from localhost ([::1]:46896 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1isA0l-0003Or-4Z for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Jan 2020 13:36:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37887) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1is9xm-0001u9-Nc for emacs-devel@gnu.org; Thu, 16 Jan 2020 13:33:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1is9xi-0003VB-PA for emacs-devel@gnu.org; Thu, 16 Jan 2020 13:33:50 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:32951) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1is9xg-0003Sc-Ta for emacs-devel@gnu.org; Thu, 16 Jan 2020 13:33:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1579199615; bh=rujLFSKYk+XN6xvMe6owuNO+ls+5zgg3M1Xt1MKIGYI=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=cmWI5IjB0NCAJzBFK5NJG64kTJdbHgG89VpC/Xr7epn7PysrfheuP8Sf6VxPI9y8n xc+dwkUg1+IWUUHDfyjF8WM4uZffiEms6h7KWcMw+27UjZRWkuOLTkD0cXE1NR0K8D BIQd5+prT1OMN0ZFKKUGcPuKH2NnEAbEyxWwfRSc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.168]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MNKlu-1jGzGX0JGk-00OoHL; Thu, 16 Jan 2020 19:33:35 +0100 In-Reply-To: <35329f93-d7a9-e845-ddb4-9c4edec5fb43@yandex.ru> Content-Language: en-US X-Provags-ID: V03:K1:F2aLmkl8qTjdVIc8npoDtLgs6nurkgi6LVb3eTnOxD2Mzmo2Rl5 r4q9cPrqzrqiQ0t7n3x202QcwqGfL6xdD/BkT0VNlsbqtAmxUtZx/vefxXrDbMGfUUKZDcB KTKVAP3c0yYv7r1pWxPJkeKIq0ezn7U38YnnVdlDD7SBoW760QbD27N4SF6iRJxt0YGaND0 XaMWplO5Mnlzvu1tZhSOw== X-UI-Out-Filterresults: notjunk:1;V03:K0:nfqSagF2o2k=:ydUHbf7uARx7bFzbsalAfT JxHsXLcfc9oumOX81TIbu+3IUH5IiecZtElWwdRc/fn2XdXiJzobqjgkqHLATemvRput6xtwD aCgbMJUgyRrqqvnItzM3ggyKMIvGA1XcXXvVfdN+t/i/bwnCLwqp6SecybQOLWGhr4FDrzZTa /gTIGIoMuXoed8YZY3xLavnVMNclOSz13mfhltDDkUSeLWFotJ4jAML5Mvwg9a3SL6f2+M25E 6n/UdAmWBSlvGPs9rin+JwQeClOzqrw7AznzksfvkTdAWrBbduDHbz7GN/LRuRCLuluptXy6q tq4RWbOIbNY4rHXhQsk75yRp5JDuTNZ+kLBcMasm63aXnJwTSAwtrt1iXs1HIOx7bI+cWKQlu QvHRkxIcieaKzIjCNkeknYDSUqVvSmVIlDTQR+jDSnLWsEfVnYMC4nSl4cz28Ymaqv2XKo8m+ KqU4KskD8ENj/svISXSjOpIh7/aCx/gSzjNqHRiAZtPCHguDjnVqs0c6QD0+jhQX78lgaBU63 ymwiq8QbTwc2PT9EE0Xr3lXai1AByDCGfEVym+zqcVq2EA5q0QHIMzyNtpNZ+lzUKJ8KhhQk+ 2h03dXER8SIvxUcJVLhgSKT/fDYN0uUVWWkINDQZEgRQMCkJQlyExIOGWt/8wp6GQIMtlIgu7 T2NnN1RWYVCt9OwYaD5SSKKsLykOdjuUKkx93yCo0MhB8cPDQJIc9sRHmRkul7sANrnLzq+Vg LPS+OpD7A4EjwlqnFAszOsINcL9lXU852/FAwC7cTb1SyMC0PKHu+1g03Ub80CukUAXICkYh X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.17.21 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:244304 Archived-At: > My intuitive understanding is that the WM considers this frame > fixed-size for some reason. And when mouse dragging of the top border > is initiated, it is indeed resized by moving the top border. > > And then some other piece of code somewhere sees that and thinks, hey, > this window must be X height! And fixes the situation by resizing it > back (but moving the bottom border). Which makes the frame move. Tracking that red border is something Emacs internal and is eventually translated to gtk_window_resize calls just like 'set-frame-size' and setting the 'height' or 'width' frame parameters. Hence, all your earlier attempts to resize the frame would then have resulted in frame movements as well. What I'm more concerned about here is that mutter actually _moves_ the frame although there should not be any decorations that would make such movement possible and not that dragging the red border does not resize the frame because I already knew from your earlier observations that resizing child frames is not supported. You could try one more thing: Set the frame's 'override-redirect' parameter to bypass the WM like (custom-set-faces '(internal-border ((t (:background "red"))))) (defun open-test (buffer) (display-buffer-in-child-frame buffer '((child-frame-parameters . ((width . 40) (height . 10) (top . 50) (left . 50) (minibuffer . nil) (override-redirect . t) (border-width . 0) (internal-border-width . 10) (drag-internal-border . t) (drag-with-mode-line . t) ))))) (setq-local test-buffer (get-buffer-create "*test child-frame*")) (setq-local test-frame (window-frame (open-test test-buffer))) And also make sure that 'frame-resize-pixelwise' is t although I doubt that this would make any difference. I've tried to read the mutter source code but hardly found anything revealing. BTW, did you ever try shrinking the initial frame instead of growing it? martin