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: Sat, 1 Feb 2020 01:22:00 +0300 Message-ID: References: <2056a194.3971.16f8d4dd4c5.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> <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> 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="39703"; 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 Fri Jan 31 23:22:44 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 1ixegV-000AJ1-SZ for ged-emacs-devel@m.gmane-mx.org; Fri, 31 Jan 2020 23:22:43 +0100 Original-Received: from localhost ([::1]:60360 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ixegU-0005Ge-VQ for ged-emacs-devel@m.gmane-mx.org; Fri, 31 Jan 2020 17:22:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54630) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ixeft-0004rx-Ln for emacs-devel@gnu.org; Fri, 31 Jan 2020 17:22:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ixefs-0004e1-Gt for emacs-devel@gnu.org; Fri, 31 Jan 2020 17:22:05 -0500 Original-Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]:44360) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ixefs-0004Zq-9R for emacs-devel@gnu.org; Fri, 31 Jan 2020 17:22:04 -0500 Original-Received: by mail-lf1-x12f.google.com with SMTP id v201so5912764lfa.11 for ; Fri, 31 Jan 2020 14:22: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=y8Bcn1/j75D7z9TWH8okNI0S6tOl02Rajpramv6SqJ4=; b=uQW4OtXEncGdeUjIDKJdQGx5imxFLGgTOL+W6XBVyhsZJ0sAzKfZdEHGXCNC+dVGZ/ +HvN7pcQ6OxisfS9+KcNKeSn6N8BHGupIgrZjrxXr5wuTgcQnDrj7B+FU7+0zz5taG1t SpUY0oVrYfeopieO1hbT5qKX4S0E4JXy5XQLjwi5FerqaKYS7BNnvWwIfBKi4+jD8K6P wPc2QPDa7FL+Y4qVgm5jbUr/LsEwaJnCWcmqAlqIHLfWYW6v2XDyMz1RGzsoKC5Tpvqm xU24ppF5AOUiqbuG+wWIKM/IzwUis2rtiyFmi/ejPQwPZTEIjILQ+MaBZjh/12y7iFSQ AmYQ== 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=y8Bcn1/j75D7z9TWH8okNI0S6tOl02Rajpramv6SqJ4=; b=j3wcEo42rWQ/YJ81cGdVx1AxSwl2EqfugWkDkQRgzNEKe3fnTFzN/02LvQrlJXwdow kDQY9bqKwea5K5MVZV0j5wbnf+FPvGcl4LU7bztCUs2tqkTs1NafjX2s1mBzUeDgzwns rNg1CgM/Li6Sg8GjvPE6yud/Idvdcy9da3OuikbLSp6wzkwuJi1tobm75U/Duzc3IFrA PDhMfJRy3Jh0JToNwAg2gdkYtvXXDWzWJ1dI9LuZESSLX1k6pXrN5bnnhQkytWG87Oer v05FJJhYG82uA/0TsGCZ29l9hx5SwWTd8ATfVxZwFpR3rg1tLLmH7aCVQaAN2NOFX2BF EMfg== X-Gm-Message-State: APjAAAXzqDMA1eBLGyjGloGRUnOAIL19G4OzSh+8Q/ONHy8AIaNvLsHz KbpYqvdGwWdbCMzHMcaYt9HxyFp+zbI= X-Google-Smtp-Source: APXvYqwsGUckjLhfPP3osFqrANFmbJxLBa+R7qn/vzLN1Pnw6BJPC/tRfHCMXMq+m7HArAmCPzYpVg== X-Received: by 2002:a19:a07:: with SMTP id 7mr6411550lfk.66.1580509322248; Fri, 31 Jan 2020 14:22:02 -0800 (PST) Original-Received: from [192.168.1.142] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id e20sm5271751ljl.59.2020.01.31.14.22.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jan 2020 14:22:01 -0800 (PST) In-Reply-To: <44010781-43f0-3bc3-06ed-475c526dee36@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::12f 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:244801 Archived-At: On 31.01.2020 18:44, martin rudalics wrote: > > Considering scaling was only a problem for GTK, that doesn't sound > > like success. Anyway, resizing normal undecorated frames in GTK seems > > to work just as well now. Resizing child frame (with scaling on) is > > still broken (but looks a bit different, no jumping around, at least). > > Presumably resizing child frames is still broken with scaling off too. I somehow forgot we had that problem with GTK builds. There is a change: I can now resize a child frame with the mouse to a size *smaller* than it was originally. As well as move its top-left corner, within certain parameters. Further than that, either Emacs stops me, or the right (or bottom, or both) border hides from view. > > With GTK build frame resizing also doesn't honor non-pixelwise > > resizing. When frame-resize-pixelwise is nil, resizing routinely eats > > into internal borders (right and bottom ones). > > Right.  I'll attach a patch that fixes it. That seems fixed, thank you. > Maybe we'll have to > investigate the size hints issue next.  The whole emacsgtkfixed.c stuff > (which I do not understand) troubles me considerably.  Could you try > building with GTK 2? Done that. The GTK 2 build seems all-around fine, with almost none of the issues described in this thread: child frames both move and resize fine. It works fine with scaling aside from thin scrollbars and small toolbar icons (Lucid has basically the same issues). It has similar mouse-resizing problems with undecorated frames, but your recent patch seems to have fixed that as well. So I think we could recommend using it as the workaround. > >> (benchmark 1 `(x-set-frame-size-and-position ,test-frame nil nil 50 > 50)) > >> > >> => 0.100523s > > > > Seems like a possible improvement, but still much slower than > set-frame-position with the GTK build. > > Neither of these benchmarks seems meaningful in the first place.  What > would it measure? The seemingly slowest part of operations "show popup" and "reposition popup". FWIW, it certain situations a popup will have to be repositioned every time the user types something. > Maybe tumashu can check with a version that uses > 'x-set-frame-size-and-position' whether it's still too slow on non-GTK > builds. I'd welcome such a test, yes.