From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) Date: Sat, 22 Aug 2015 16:16:47 +0200 Message-ID: <55D8844F.4080508@gmx.at> References: <55D8196B.3010206@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1440253099 21302 80.91.229.3 (22 Aug 2015 14:18:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Aug 2015 14:18:19 +0000 (UTC) Cc: 21317@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 22 16:18:10 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZT9cX-00021F-Qw for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Aug 2015 16:18:10 +0200 Original-Received: from localhost ([::1]:46702 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZT9cW-00016R-UK for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Aug 2015 10:18:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZT9cT-00016A-Ae for bug-gnu-emacs@gnu.org; Sat, 22 Aug 2015 10:18:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZT9cQ-0005Hj-1Z for bug-gnu-emacs@gnu.org; Sat, 22 Aug 2015 10:18:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43055) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZT9cP-0005Hf-VP for bug-gnu-emacs@gnu.org; Sat, 22 Aug 2015 10:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZT9cP-0005yU-N2 for bug-gnu-emacs@gnu.org; Sat, 22 Aug 2015 10:18:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Aug 2015 14:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21317 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21317-submit@debbugs.gnu.org id=B21317.144025302122886 (code B ref 21317); Sat, 22 Aug 2015 14:18:01 +0000 Original-Received: (at 21317) by debbugs.gnu.org; 22 Aug 2015 14:17:01 +0000 Original-Received: from localhost ([127.0.0.1]:35265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZT9bQ-0005ww-Q6 for submit@debbugs.gnu.org; Sat, 22 Aug 2015 10:17:01 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:60322) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZT9bO-0005wn-5W for 21317@debbugs.gnu.org; Sat, 22 Aug 2015 10:16:59 -0400 Original-Received: from [91.113.5.229] ([91.113.5.229]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LtJAR-1Yjl9m0u8R-012r2E; Sat, 22 Aug 2015 16:16:57 +0200 In-Reply-To: X-Provags-ID: V03:K0:6NUdHO2AT8Nt/NgxX+OWKd2LF8nFyyFmKndVdd+QjcnBM3lltVk /zTA5zWP0XTIlrpJphXlWtIrNC0Jm74UfrxFLoIttdLnxn/8j9EUrWGNxHNWoOE8NI19pFS b8anYvEYKCxKitIxFx/bQeSeoDzb1Kof8yf0+r29CqGC6thUGStkbYyenBAXJgBkBqriXgq o9pYWbFrGOONPoexOfDMw== X-UI-Out-Filterresults: notjunk:1;V01:K0:1va66PNCLOM=:jIyj9Vf9nCwJmAUMUCcT9e A2zb9/4ypd9sWNOjuAAcDNDG45nmE2pZVRlwmmbcIXoZkmd8SVZBxAEYt6l33zIvuPKXHjHA5 y99lCU7TdX3BtclPQFQ0eCnY5DtK7uHz6MVzp3lBBvJC2eZ+KJnHdG3TCW1yqh8GfnKcBXOOx qvft8ellUHv4rLVOGBEt8AAGxKXKMH/jxENBvCd9pejdNvKR7H9iYoIH4tVqbBLaj8WnMW0hi Yznq7FTgAm/xgew1Tvrclylc5/y1wO9W8kww50DtI06FKqFj+JTvbMFru4+e+lmpCUkQJDbTb jFqoQDM4Gy4HiQ9TBY5qDa1pVB89ZhNmC0xLBv6oLrZDbW/XAkt+f6GVDTJ0clZbXWx3l5k9l LNRiYHxsY76WHmw5boyb8tpUsb/DfO6f2TTgvDE+kutuoreLtlh5rmqdN8XGyyQPd7JOVC0JL pqIcdg7kTrLflME/ojRiY/5cL8n+5DorvGWZ/We+4zDIafYF5kWbdpzbhpT3lxRE1g96xXHCc 6Tuwt9/OruZIlFddvMziknQbJiHvzq3BXJu8JETmoIQiPj3RVPzk3PaNupy7wY7RHQjS/QFmo NFOR1yviy/m4pH6eBum16YobsPhkaprF7HcPI+l06dH4PQw3cjacALB7WiNi/XtG+rtHyK5YF TToPm6NtQrZtUvzImz3XG5QXZdQlyRTDjdHfuVzizTPDQp+Nium8sBnLNV3Vqd0HNW5jO1COW JhPNNCDJMWvLQekmQ3IEqU+w5cebSLO/dVkKSQ== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:105694 Archived-At: > Thanks for responding! Thanks for investigating! > On Sat, Aug 22, 2015 at 6:40 AM, martin rudalics wrote: >>> When starting Emacs (GTK build) on an X server which has no window >>> manager (such as a newly-created Xnest session), setting >>> `frame-resize-pixelwise' to t followed by a resize operation often has >>> no effect. >> >> According to the manual >> >> Setting this variable usually causes the next resize operation to >> pass the corresponding size hints to the window manager. This >> means that this variable should be set only in a user's initial >> file; applications should never bind it temporarily. > > That documentation is outdated and does not apply to GTK builds in all > cases, I'm afraid. It is not the window manager that decides to honor > or dishonor frame-resize-pixelwise but GDK. "Window manager" was an attempt to catch the behavior of all toolkits including Windows which doesn't have a window manager either. Feel free to suggest a better term. > See x_wm_set_size_hint and > gtk_window_move_resize (gtkwindow.c, in the GTK sources). In > particular, gtk_window_compute_configure_request calls > gtk_window_constrain_size which calls gdk_window_constrain_size which > calculates > > width = base_width + FLOOR (width - base_width, xinc); > height = base_height + FLOOR (height - base_height, yinc); > > (where FLOOR is defined as #define FLOOR(value, base) ( ((gint) > ((value) / (base))) * (base) ) ) I can't find that in the version from https://github.com/GNOME/gtk/blob/master/gtk/gtkwindow.c and also must admit that I have forgotten most of the GTK code by now. IIRC base_width and base_height are somehow calculated from a minimum size and what Emacs requested earlier. If frame_resize_pixelwise is true we _should_ have requested 1 from this size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f); size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f); Can you check how apparently an "integral" (the increment is a multiple of either FRAME_COLUMN_WIDTH or FRAME_LINE_HEIGHT) value gets passed via size_hints in your case? >> So it's possible that Xnest or some other X component refuses to resize >> your frame because the size hints were set up inappropriately. > > I'm pretty sure that's not what's happening, but I'll be happy to > provide traces to demonstrate my analysis is correct...or to prove it > wrong, of course! The attached gdb log shows quite clearly that it's > GDK making the second (erroneous) call to XResizeWindow, not Xnest > (there is no window manager). OK. I won't doubt what you say here. >> Does it also fail when `frame-resize-pixelwise' is set to t in your >> initial file? > > Yes, it does. That's bad. It can only mean that we send an integral resize request _before_ Emacs reads the initial file and the subsequent "real" resize request fails because the size hints have been already set up wrongly. >> Does it fail when you set `frame-resize-pixelwise' to t, request an >> integral resize first and a second non-integral one afterwards? > > I'm not sure I fully understand how you define "integral". See above. Also the "first and a second" above was meant to do this in two consecutive commands (that is, with a redisplay in between). Passing different size requests in one and the same command can have unpredictable consequences (at least on other platforms). > In short, > non-full-screen resize + redisplay + full-screen resize works, the > other combinations do not. > > If I run this code (Xnest running on display :3): > > DISPLAY=:3 emacs -Q --eval "(progn (setq frame-resize-pixelwise t) > (set-frame-height (selected-frame) (1+ (frame-pixel-height > (selected-frame))) nil t) (redisplay) (set-frame-parameter > (selected-frame) 'fullscreen 'fullboth))" > > Things work, but without the "(redisplay)" they don't. (So that's a > non-full-screen resize first, then a full-screen resize). Doing the > full-screen resize first breaks things. "Breaks" in what sense? That it does nothing or not fully resize? > I must also point out that without the "(redisplay)", there are > unexpected results: the full screen resize appears to be ignored > entirely. I'd have expected that. > But, again, I currently stand by my initial analysis of what's > happening. The problem is that we cannot simply do the right thing > because of the KWin bug... What is the "KWin bug"? I'm probably too silly to give you a good advice. However, in xg_frame_set_char_size (which is responsible for the resize in the GTK case) we could do the x_wm_set_size_hint (f, 0, 0); _before_ calling gtk_window_resize. Could you play around with that? BTW if you set `frame-size-history' to a non-nil value you should get a list of frame resizing operations you can watch with the function `frame--size-history'. IIRC I found GDB occasionally not 100% reliable to reproduce the actual history as of a normal, optimized build. martin