From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.bugs Subject: bug#19990: 24.4; Bad resizing interaction when WM ignores size hints Date: Fri, 6 Mar 2015 18:05:26 +0100 Message-ID: <2C962D9B-843A-44B2-9FFB-1CF60F30D962@swipnet.se> References: <54F59D19.5000808@eurac.edu> <54F5F3C9.9070008@gmx.at> <54F6003E.7040900@eurac.edu> <54F752C8.7050009@gmx.at> <54F754A4.5050507@eurac.edu> <8D5FE96A-F0AE-4908-8AEF-DFDBAB504983@swipnet.se> <54F80E26.1070608@gmx.at> <54F885F7.80803@swipnet.se> <54F89D48.1000902@gmx.at> <9C8ADD7C-C99B-4C5E-9835-AD446CC57747@swipnet.se> <54F9718B.8070409@gmx.at> <54F98714.10603@eurac.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1425661582 25604 80.91.229.3 (6 Mar 2015 17:06:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Mar 2015 17:06:22 +0000 (UTC) Cc: 19990@debbugs.gnu.org To: Yuri D'Elia Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 06 18:06:11 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 1YTvhS-0000fL-SJ for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Mar 2015 18:06:11 +0100 Original-Received: from localhost ([::1]:59397 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTvhS-0002oz-6B for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Mar 2015 12:06:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59147) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTvhN-0002lK-RR for bug-gnu-emacs@gnu.org; Fri, 06 Mar 2015 12:06:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTvhK-0006lA-Vn for bug-gnu-emacs@gnu.org; Fri, 06 Mar 2015 12:06:05 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39172) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTvhK-0006l2-RS for bug-gnu-emacs@gnu.org; Fri, 06 Mar 2015 12:06:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YTvhK-00033r-Dw for bug-gnu-emacs@gnu.org; Fri, 06 Mar 2015 12:06:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Jan D." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Mar 2015 17:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19990-submit@debbugs.gnu.org id=B19990.142566153911728 (code B ref 19990); Fri, 06 Mar 2015 17:06:02 +0000 Original-Received: (at 19990) by debbugs.gnu.org; 6 Mar 2015 17:05:39 +0000 Original-Received: from localhost ([127.0.0.1]:37740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YTvgv-000332-Iq for submit@debbugs.gnu.org; Fri, 06 Mar 2015 12:05:38 -0500 Original-Received: from mailfe06.swip.net ([212.247.154.161]:42365 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YTvgr-00032g-Q8 for 19990@debbugs.gnu.org; Fri, 06 Mar 2015 12:05:34 -0500 X-T2-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_40 Original-Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 575454109; Fri, 06 Mar 2015 18:05:26 +0100 In-Reply-To: <54F98714.10603@eurac.edu> X-Mailer: Apple Mail (2.2070.6) 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: 140.186.70.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:100176 Archived-At: > 6 mar 2015 kl. 11:53 skrev Yuri D'Elia : > > On 03/06/2015 10:21 AM, martin rudalics wrote: >> The OP said that: >> >> I force the emacs frame to take the height of the entire screen. >> >> So this looks like a fullheight frame to me without, apparently, >> explicitly specifying it as such. > > I should have never said 'full screen height', since this keeps > confusing you. In my particular configuration, I have no window borders, > so two windows side-by-side will automatically fit the screen height. > This is *not* a special case for a tiling window manger. > > A tiling window manager will force the frame to fit a screen region, > _possibly_ ignoring size hints. That's all there is to it. It does that > *intentionally*, since you can imagine that having gaps between the > tiles is just plainly annoying. In a side-by-side configuration, you > don't want gaps on the lower corner of the screen. > >> Maybe the OP's problem is that the Window manager conceptually gives >> Emacs the full height of the screen and Gtk+ is not aware of that. >> Maybe also Gtk+ doesn't even understand fullheight. At least I can't >> detect an entry for it in GtkWindowPrivate which OTOH has a 'tiled' >> entry. > > The problem with Gtk+ is that it tries to handle hints both on behalf of > the window manger and on the client. I have *no* clue of why it does > that. Maybe to handle TWM? Or more probably to handle the "Windows" port > which has no such feature? Thats sounds reasonable. Probably also Wayland which has no window manager. > > The second issue with Gtk+ is that it notifies the application while > doing his own hint handling (or again, is that intentional?). > > I would be perfectly happy to discuss this issue with Gtk+ folks, but I > remember that back in Gtk 1.3/2.0 days, many of my patches where > rejected since they fixed behavior that wasn't really intended "for the > common user", whatever that means. Gtk 3 seems to have regressed even > more in this area, so I just gave up in trying to argue. I have no better experience than you. > > To sum up, however, what about this: > > Since we receive the first ConfigureNotify event with the unhinted > width/height, we *can* detect that the size hints have been ignored. > Couldn't we disable them at that point? At what point would we re-enable them? > This would fix Gtk+ trying to do > a reconfiguration attempt and remove the following two useless events. > This looks like a simple fix that would already improve the current > configuration, but I would need experience with the Mac/Win port to tell > if Gtk would fail in this scenario. Maybe an "ifdef X11" is required. The NS/W32 port of Emacs can't use Gtk+ so it is already X11 only. > > The question then becomes: would actually be possible to set the hints > immediately back on, so that in a further resize request the WM sees the > hints, but *without* having Gtk+ do it's mess? This would mean that we > would need to set the hints back on when the resize request has been > fully settled. Tricky. Setting them back-on on a further repaint/focus > in/out event is either too late or not enough. > > As mentioned in my first request, this is a minor nuance fix for folks > with tiling window managers. My point is "can we handle it better?". Jan D.