From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Emacs's set-frame-size can not work well with gnome-shell? Date: Mon, 10 Feb 2020 10:06:00 +0300 Message-ID: <71cd5683-412f-de8d-d1b6-31352a4454ba@yandex.ru> References: <2056a194.3971.16f8d4dd4c5.Coremail.tumashu@163.com> <4a424bf3-ee08-b114-73ef-287bde14003b@gmx.at> <5dd35cdd-2914-0b91-a6fd-e8764feecfb0@gmx.at> <9839e101-a25d-8875-4eee-2e6772249afe@yandex.ru> <728856fd-dab1-eade-54f5-6ba2c299373a@gmx.at> <6c775e15-1113-8406-5583-97c259305a7d@yandex.ru> <0fe2d245-9ac1-3528-e710-38462441f8aa@gmx.at> <9bac54df-8cd3-303d-910e-07e161ff1f3e@gmx.at> <414ade05-1ae6-75c2-9af1-e1eee42799a0@yandex.ru> <44010781-43f0-3bc3-06ed-475c526dee36@gmx.at> <70813591-8c24-cb30-8ecf-0c413a51f472@gmx.at> <81215100-3476-9d2c-f535-f57fbd18fd8b@yandex.ru> <8a485c09-535a-97e6-9817-31e6d2f93adb@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="119294"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: "emacs-devel@gnu.org" To: martin rudalics , tumashu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 10 08:06:51 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 1j139e-000UvT-Sm for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Feb 2020 08:06:50 +0100 Original-Received: from localhost ([::1]:57608 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j139d-0002H6-UQ for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Feb 2020 02:06:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58659) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j138w-0001Mt-7W for emacs-devel@gnu.org; Mon, 10 Feb 2020 02:06:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j138u-0005Ft-Vt for emacs-devel@gnu.org; Mon, 10 Feb 2020 02:06:06 -0500 Original-Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]:40341) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j138u-0005Cm-Pr for emacs-devel@gnu.org; Mon, 10 Feb 2020 02:06:04 -0500 Original-Received: by mail-wr1-x432.google.com with SMTP id t3so6115986wru.7 for ; Sun, 09 Feb 2020 23:06:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8QnFb2YNHGNA6rVPnA2rRmCwukl+REHwCnaCYizKqUc=; b=E+8tD/HRAYo8O9fGDVtBEzIs/wk/jrA6fuhdcnGqvEzZlIu/IG+TMo0FxIIi8qbyNo TLoP18Mf6/3D6ZhjWIwLWF2nP7aGlk1zeyA1Zfgfh0UKrVryuFOtIWzWWPG+nxo8kzup Dl8dyH0RrMDHnuXSesfG4BhXsT8kB8msTv2CcFzr2+7yvU+3nohVn/p433MoXn23HGTa 2uYEZ0wdKlVl5tES+yz6u7RtogjdaU8q4LnMbWcIlkXxuFQg+e3rrJx/lrvUWRH175B1 fwq7+yqg9Z2Al7H+QPCF1ATkYweEod4UFjiK2c94UwBavtYxGwDysvDEPFeGidVmVJrU UX0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8QnFb2YNHGNA6rVPnA2rRmCwukl+REHwCnaCYizKqUc=; b=qDKMy9MbXFiw5hIFmvLwH3z1JnxCggYoiMShOdIrBzMm35Oa8aJ96DOdua5JDXopMy 093o1ldq0s02T0sugBhjx6SiGzWAfUuJdWs4RooPvx+ibWWyZHDxFGxZP/sfc38w/Fjj l8noZ1GXV4RSJ13SLbxiW0pbsP0YW+y4YXZlcw/oHzhu9HMKm+MFzu/QHIrosQB/8ysC PGBr7k4u9nOwnbPvP9Sq+5N6ETDucoAAyGjlb8bnUvPcLNGDiSgI2iWL4D5l7m/1xAmh ENpQkYmrdYixMwCrNkJp/hbIIYbFmtDSxguAtUwlmGVtLlJ1UyQQ2FEAtbkGZFDp1GS/ epmw== X-Gm-Message-State: APjAAAVFj27vq63mglaLT70F8YyZ+WqvUpWpHifwg1AE4SCQ4LPa7iyn odBlhHEJGwz1/oVs70xJeX9xe9Dttew= X-Google-Smtp-Source: APXvYqz7WqBhzhTemVzcpD4rt/ls2IKvSO3b1YWFNdKrSzbGe+hogd6bLMWjqt8Tbj8F1NRRqCsWeA== X-Received: by 2002:a5d:56ca:: with SMTP id m10mr2460wrw.313.1581318362916; Sun, 09 Feb 2020 23:06:02 -0800 (PST) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id r6sm15491612wrq.92.2020.02.09.23.06.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Feb 2020 23:06:01 -0800 (PST) In-Reply-To: <8a485c09-535a-97e6-9817-31e6d2f93adb@gmx.at> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::432 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:244903 Archived-At: On 05.02.2020 12:15, martin rudalics wrote: > >> Does making the initial child frame very large > >> give you more room to move? > > > > Yes, as per the above. > > So you could make the initial child frame 10000 pixel wide and high and > resizing would never fail? Seems like it. But set-frame-size still does nothing, so I wouldn't know how to take advantage of this discovery programmatically. > >> (1) Pursue the previous idea to use X calls instead of gtk calls for > >> resizing child frames.  For this purpose, on top of mouse+xfns.diff > >> please change the > >> > >>      gdk_window_move_resize > >>        (window, left / scale, top / scale, new_pixel_width / scale, > >>         new_pixel_height / scale); > >> > >> call to > >> > >>        if (FRAME_PARENT_FRAME (f)) > >>      XMoveResizeWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), > >>                 left / scale, top / scale, new_pixel_width / scale, > >>                 new_pixel_height / scale); > >>        else > >>      gdk_window_move_resize > >>        (window, left / scale, top / scale, new_pixel_width / scale, > >>         new_pixel_height / scale); > >> > >> If this works but gives problem with scaling, then drop all " / scale" > >> instances in the XMoveResizeWindow call. > > > > Didn't help. The patch, as-is, introduced a scaling problem. And > > dropping "/ scale" instances > > Which ones did you drop - all?  The ones in the gdk_window_move_resize > call should remain, only the ones from the XMoveResizeWindow call should > be dropped. Only the ones from the XMoveResizeWindow call. > I meanwhile installed mutter here.  Debian apparently doesn't resolve > the dependencies well so I had to manually install some additional > gnomish features.  The whole thing still looks incomplete though. Sounds like trying a Live CD might work better for you. That leaves the question of how to get an Emacs build on there, though. > The frame positioning behavior of mutter is a pain for me and renders my > usual Emacs frame setup practically unusable.  It's possibly a > consequence of making borders invisible and having the frame minimize > and maximize when it's pushed against the bottom or top edge of the > display.  Visible child frames never resize, I cannot even shrink them. > Also, I can't get vertical scroll bars for them.  In one case I was told > > Window manager warning: Window 0x4a0003d (Terminal) sets an MWM hint > indicating it isn't resizable, but sets min size 1 x 1 and max size > 2147483647 x 2147483647; this doesn't make much sense. > > but I'm not even sure whether these resulted from an Emacs frame - the > max size values are not ours AFAICT.  Also we set MWM hints only from > within non-GTK builds, maybe I've been running one of them. Sounds like it's talking about the "Terminal" app? > Anyway, I meanwhile further rewrote the code for mouse dragging and > 'x-set-frame-size-and-position', patch attached.  I also added an > interface to the gtk inspector, you can enable it via > > (when (fboundp 'x-gtk-debug) >   (x-gtk-debug t)) > > Maybe you can derive something from running it.  At least here, when > under "visual" turning on "graphics actualizations", I can clearly see > that GTK processes and passes on the resize requests for child frames > (by turning the frame red) and that they are later apparently dismissed > by mutter. Will do! Although it sounds like you probably have all the same information now.