From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Pip Cet 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 15:32:02 +0000 Message-ID: References: <55D8196B.3010206@gmx.at> <55D8844F.4080508@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=001a113ed2f80eeb56051de816f7 X-Trace: ger.gmane.org 1440257608 22955 80.91.229.3 (22 Aug 2015 15:33:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Aug 2015 15:33:28 +0000 (UTC) Cc: 21317@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 22 17:33:19 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 1ZTAnB-0003y3-1a for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Aug 2015 17:33:13 +0200 Original-Received: from localhost ([::1]:46928 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTAnA-0000Pq-6I for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Aug 2015 11:33:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50408) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTAn5-0000PB-0Y for bug-gnu-emacs@gnu.org; Sat, 22 Aug 2015 11:33:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZTAn0-0003Z6-S0 for bug-gnu-emacs@gnu.org; Sat, 22 Aug 2015 11:33:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43094) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTAn0-0003Yx-Oh for bug-gnu-emacs@gnu.org; Sat, 22 Aug 2015 11:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZTAn0-0007iC-Ec for bug-gnu-emacs@gnu.org; Sat, 22 Aug 2015 11:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Aug 2015 15:33:02 +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.144025752729584 (code B ref 21317); Sat, 22 Aug 2015 15:33:02 +0000 Original-Received: (at 21317) by debbugs.gnu.org; 22 Aug 2015 15:32:07 +0000 Original-Received: from localhost ([127.0.0.1]:35304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTAm6-0007h3-I3 for submit@debbugs.gnu.org; Sat, 22 Aug 2015 11:32:07 -0400 Original-Received: from mail-io0-f178.google.com ([209.85.223.178]:35521) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTAm3-0007gt-PZ for 21317@debbugs.gnu.org; Sat, 22 Aug 2015 11:32:04 -0400 Original-Received: by iodt126 with SMTP id t126so110178247iod.2 for <21317@debbugs.gnu.org>; Sat, 22 Aug 2015 08:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ur0yfCawEj5YcRI6timf3WQP8VnN/1adPPrXF0X7nTc=; b=rvLUAd711jL7PijdtxEJyWWTSPnwdoTux8O+TA1ET7ygto8XcG1WDYyIJy/PPbvrGv RfWEEOI+GiD6ywH0zS7wkrps4aF8pCApB510ov+pFHY9CIF3SYuHPrCJqqDxbExeCyTW nUK4vAYe+Dy6Llr1ZHdtMJeZlhKmwXQULRo9nve9ob8OYX4gIVg2jzrwhgmHLE+u7HH5 RD3Iq4L7GM92npDq0JBT3aomIU0P+ufNJP05fBKMzskVIAA7A4I6gZBv3yPxY3TpmFHF rPuARxrTTnmjMmpc8IRLWANERk0K1GoyTW7MI/JCESHYoDRFFjKNOHgR8HKiz3WMdJiD ntSQ== X-Received: by 10.107.132.139 with SMTP id o11mr11696035ioi.3.1440257523237; Sat, 22 Aug 2015 08:32:03 -0700 (PDT) Original-Received: by 10.79.78.66 with HTTP; Sat, 22 Aug 2015 08:32:02 -0700 (PDT) In-Reply-To: <55D8844F.4080508@gmx.at> 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:105700 Archived-At: --001a113ed2f80eeb56051de816f7 Content-Type: text/plain; charset=UTF-8 Let me just repeat my initial analysis, which I still believe is correct and which might have gotten lost somewhere. There are two problems: (1) x_check_fullscreen (xterm.c) calls XResizeWindow without first calling x_wm_set_size_hint (gtkutil.c), which would propagate the `frame-resize-pixelwise' flag to have an effect on GTK/GDK (2) x_wm_set_size_hint returns without propagating the `frame-resize-pixelwise' flag when the frame's fullscreen property is 'maximized or 'fullboth. The first appears to be simple oversight, but the second is intentional to work around a KWin bug. I've attached a patch which fixes things for me (at least when tool-bar-mode is disabled :( ), but presumably breaks things for KWin users, so it should not go in as it is until that matter has been cleared; maybe that'll help clarify matters. I take it something about that doesn't feel right to you, and that's reason enough to investigate further. On Sat, Aug 22, 2015 at 2:16 PM, martin rudalics wrote: >> 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. Oh, I see! That makes sense, thank you and sorry for my narrow-mindedness in thinking only of X11 window managers. >> 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 Try https://github.com/GNOME/gtk/blob/master/gdk/gdkwindow.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); We do hit that code (in gtkutil.c) twice: once during early initialization, when frame_resize_pixelwise is still false, and once after GDK has decided to resize us to not-quite-full-screen size, when it's too late. We should hit it once more, from x_check_fullscreen, but don't do so for the two reasons listed above. > 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? Oh, I see what you mean now. I'll investigate that next. >>> 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. Feel free to, of course, though I understand sifting through gdb logs is best avoided unless it's absolutely necessary. >>> 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. No, we call Fsetq and so on fine, I think it's just that we never call x_set_wm_size_hints afterwards. >>> 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). Noted. Thanks for that piece of advice, that really helps me make sense of what's going on. >> 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? It appears to ignore the fullscreen resize; as you point out, that's as expected, by the "don't resize twice without a redisplay" rule. >> 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. Good, that's one less thing to worry about then. >> 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"? http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14627, which introduced the conditional which prevents us from calling x_wm_size_hints > I'm probably too silly to give you a good advice. Not at all, it's much appreciated. > However, in > xg_frame_set_char_size (which is responsible for the resize in the GTK > case) we could do the That's a very interesting point, because xg_frame_set_char_size never appears to get called here after early initialization. Instead, we call XResizeWindow directly, then GDK catches the ConfigureNotify and decides it doesn't like it, so it sends another (erroneous) XResizeWindow. > 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. Thanks, I never considered that possibility. I'm running an unoptimized debug build (-O0 -g3), but there might be useful information there. So far it appears not to contain anything unexpected (I'm looking at the variable directly, the function appears to have mysteriously vanished from the current git tree, except for a reference in the documentation...) Thanks for all your help! --001a113ed2f80eeb56051de816f7 Content-Type: text/plain; charset=US-ASCII; name="emacs-bug-008.diff" Content-Disposition: attachment; filename="emacs-bug-008.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_idn84ptw0 RnJvbSAxZjNmNjhiMmE2ZGE0YzlkMGI1NGYxOGIwYmNjNmM0ZGQyYjI0M2FkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXAgPHBpcGNldEBnbWFpbC5jb20+CkRhdGU6IFNhdCwg MjIgQXVnIDIwMTUgMTQ6NTk6MTAgKzAwMDAKU3ViamVjdDogW1BBVENIXSBEbyBub3QgYXBwbHkg dGhpcyBwYXRjaC4KClNlZSBodHRwOi8vZGViYnVncy5nbnUub3JnL2NnaS9idWdyZXBvcnQuY2dp P2J1Zz0xNDYyNwotLS0KIHNyYy9ndGt1dGlsLmMgfCAxMSAtLS0tLS0tLS0tLQogc3JjL3h0ZXJt LmMgICB8ICAyICsrCiAyIGZpbGVzIGNoYW5nZWQsIDIgaW5zZXJ0aW9ucygrKSwgMTEgZGVsZXRp b25zKC0pCgpkaWZmIC0tZ2l0IGEvc3JjL2d0a3V0aWwuYyBiL3NyYy9ndGt1dGlsLmMKaW5kZXgg ZDY4NGNkOS4uYmRiZmIwZCAxMDA2NDQKLS0tIGEvc3JjL2d0a3V0aWwuYworKysgYi9zcmMvZ3Rr dXRpbC5jCkBAIC0xMzY0LDcgKzEzNjQsNiBAQCB4X3dtX3NldF9zaXplX2hpbnQgKHN0cnVjdCBm cmFtZSAqZiwgbG9uZyBpbnQgZmxhZ3MsIGJvb2wgdXNlcl9wb3NpdGlvbikKICAgaW50IGJhc2Vf d2lkdGgsIGJhc2VfaGVpZ2h0OwogICBpbnQgbWluX3Jvd3MgPSAwLCBtaW5fY29scyA9IDA7CiAg IGludCB3aW5fZ3Jhdml0eSA9IGYtPndpbl9ncmF2aXR5OwotICBMaXNwX09iamVjdCBmc19zdGF0 ZSwgZnJhbWU7CiAgIGludCBzY2FsZSA9IHhnX2dldF9nZGtfc2NhbGUgKCk7CiAKICAgLyogRG9u J3Qgc2V0IHNpemUgaGludHMgZHVyaW5nIGluaXRpYWxpemF0aW9uOyB0aGF0IGFwcGFyZW50bHkg bGVhZHMKQEAgLTEzNzMsMTYgKzEzNzIsNiBAQCB4X3dtX3NldF9zaXplX2hpbnQgKHN0cnVjdCBm cmFtZSAqZiwgbG9uZyBpbnQgZmxhZ3MsIGJvb2wgdXNlcl9wb3NpdGlvbikKICAgaWYgKE5JTFAg KFZhZnRlcl9pbml0X3RpbWUpIHx8ICFGUkFNRV9HVEtfT1VURVJfV0lER0VUIChmKSkKICAgICBy ZXR1cm47CiAKLSAgWFNFVEZSQU1FIChmcmFtZSwgZik7Ci0gIGZzX3N0YXRlID0gRmZyYW1lX3Bh cmFtZXRlciAoZnJhbWUsIFFmdWxsc2NyZWVuKTsKLSAgaWYgKEVRIChmc19zdGF0ZSwgUW1heGlt aXplZCkgfHwgRVEgKGZzX3N0YXRlLCBRZnVsbGJvdGgpKQotICAgIHsKLSAgICAgIC8qIERvbid0 IHNldCBoaW50cyB3aGVuIG1heGltaXplZCBvciBmdWxsc2NyZWVuLiAgQXBwYXJlbnRseSBLV2lu IGFuZAotICAgICAgICAgR3RrMyBkb24ndCBnZXQgYWxvbmcgYW5kIHRoZSBmcmFtZSBzaHJpbmtz ICghKS4KLSAgICAgICovCi0gICAgICByZXR1cm47Ci0gICAgfQotCiAgIGlmIChmbGFncykKICAg ICB7CiAgICAgICBtZW1zZXQgKCZzaXplX2hpbnRzLCAwLCBzaXplb2YgKHNpemVfaGludHMpKTsK ZGlmZiAtLWdpdCBhL3NyYy94dGVybS5jIGIvc3JjL3h0ZXJtLmMKaW5kZXggYjdhYWNmYS4uMGZk MjQ2NCAxMDA2NDQKLS0tIGEvc3JjL3h0ZXJtLmMKKysrIGIvc3JjL3h0ZXJtLmMKQEAgLTEwMTg5 LDYgKzEwMTg5LDggQEAgeF9jaGVja19mdWxsc2NyZWVuIChzdHJ1Y3QgZnJhbWUgKmYpCiAgICAg ICBmcmFtZV9zaXplX2hpc3RvcnlfYWRkCiAJKGYsIFF4X2NoZWNrX2Z1bGxzY3JlZW4sIHdpZHRo LCBoZWlnaHQsIFFuaWwpOwogCisgICAgICB4X3dtX3NldF9zaXplX2hpbnQgKGYsIDAsIGZhbHNl KTsKKwogICAgICAgWFJlc2l6ZVdpbmRvdyAoRlJBTUVfWF9ESVNQTEFZIChmKSwgRlJBTUVfT1VU RVJfV0lORE9XIChmKSwKIAkJICAgICB3aWR0aCwgaGVpZ2h0KTsKIAotLSAKMi41LjAKCg== --001a113ed2f80eeb56051de816f7--