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#19990: 24.4; Bad resizing interaction when WM ignores size hints Date: Fri, 06 Mar 2015 19:54:33 +0100 Message-ID: <54F9F7E9.8000106@gmx.at> 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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1425668446 10575 80.91.229.3 (6 Mar 2015 19:00:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Mar 2015 19:00:46 +0000 (UTC) Cc: 19990@debbugs.gnu.org To: Yuri D'Elia , "Jan D." Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 06 20:00:36 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 1YTxUB-0002zr-Ct for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Mar 2015 20:00:35 +0100 Original-Received: from localhost ([::1]:59857 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTxUA-0008Dq-QH for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Mar 2015 14:00:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55105) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTxOs-0006RU-5N for bug-gnu-emacs@gnu.org; Fri, 06 Mar 2015 13:55:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTxOo-0000fs-Tc for bug-gnu-emacs@gnu.org; Fri, 06 Mar 2015 13:55:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39233) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTxOo-0000fn-QX for bug-gnu-emacs@gnu.org; Fri, 06 Mar 2015 13:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YTxOo-00079d-HY for bug-gnu-emacs@gnu.org; Fri, 06 Mar 2015 13:55:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Mar 2015 18:55: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.142566809527481 (code B ref 19990); Fri, 06 Mar 2015 18:55:02 +0000 Original-Received: (at 19990) by debbugs.gnu.org; 6 Mar 2015 18:54:55 +0000 Original-Received: from localhost ([127.0.0.1]:37801 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YTxOg-00079A-LJ for submit@debbugs.gnu.org; Fri, 06 Mar 2015 13:54:55 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:56416) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YTxOd-00078s-Tv for 19990@debbugs.gnu.org; Fri, 06 Mar 2015 13:54:52 -0500 Original-Received: from [178.191.142.164] ([178.191.142.164]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MOwY7-1YQuJx1rYF-006Kjr; Fri, 06 Mar 2015 19:54:42 +0100 In-Reply-To: <54F98714.10603@eurac.edu> X-Provags-ID: V03:K0:lAXUUJOyArFDdR4gsiLflKV0FzNdzuKLKiNKT9qyIwJqqp/6tcz KFBDJ40BMWM6TKAb3PJJngFKKF9I6ccXRn1hgE6qo3rvg1wZzQkptQZ5EDmiVSShPw573u8 Qww8R3f02WmtIh8IqjFdLRgr+BrJo2WrH217JnQfJ+atnTXeAHlr23Z1YF/o3mUFEFSYgHx /1AZQX2BI+Zkx2eFA9nag== X-UI-Out-Filterresults: notjunk:1; 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:100184 Archived-At: > 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. Accepted. The frame is not fullheight; it just is as high as the screen. > 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. > > 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? This was the idea of "intercepting" I mentioned earlier. > 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. You can ignore other ports in this regard. > 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. I'm afraid this is the hard part. Emacs would have to know that the window manager has stopped tiling. I already said that GtkWindowPrivate has a `tiled' entry. I have no idea who can use or set that. > 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?". martin