From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: size hints and tiling window managers Date: Sun, 09 Dec 2012 21:36:16 +0200 Message-ID: <83a9tnc91r.fsf@gnu.org> References: <87zk1r104d.fsf@bernoul.li> <50C1C678.5040805@gmx.at> <838v98nci1.fsf@gnu.org> <87boe3t4gd.fsf@bernoul.li> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1355081794 14546 80.91.229.3 (9 Dec 2012 19:36:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Dec 2012 19:36:34 +0000 (UTC) Cc: rudalics@gmx.at, cloos@jhcloos.com, emacs-devel@gnu.org To: Jonas Bernoulli Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 09 20:36:47 2012 Return-path: Envelope-to: ged-emacs-devel@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 1ThmgA-0005JZ-Oi for ged-emacs-devel@m.gmane.org; Sun, 09 Dec 2012 20:36:46 +0100 Original-Received: from localhost ([::1]:45373 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Thmfy-0001vu-BL for ged-emacs-devel@m.gmane.org; Sun, 09 Dec 2012 14:36:34 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Thmfv-0001un-5Q for emacs-devel@gnu.org; Sun, 09 Dec 2012 14:36:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Thmft-0002k0-Gw for emacs-devel@gnu.org; Sun, 09 Dec 2012 14:36:31 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:45969) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Thmft-0002jc-9h for emacs-devel@gnu.org; Sun, 09 Dec 2012 14:36:29 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MES00K003OS7600@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Sun, 09 Dec 2012 21:36:27 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MES00KI33SR2970@a-mtaout23.012.net.il>; Sun, 09 Dec 2012 21:36:27 +0200 (IST) In-reply-to: <87boe3t4gd.fsf@bernoul.li> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:155405 Archived-At: > From: Jonas Bernoulli > Cc: "James Cloos" , emacs-devel@gnu.org, rudalics@gmx.at > Date: Sun, 09 Dec 2012 20:23:30 +0100 > > I have attached a screenshot that shows parts of four Emacs frames. The > green areas are the X11 window borders and window titles drawn by the > window manager. The cyan areas are the fringes. In the upper left > window I have marked what I have called the "extra space" in my initial > report. Thanks. I wanted to be sure I understand the problem. > > Changing the width of the fringes dynamically is easy, actually, > > because we already do so, albeit triggered by user commands. > > I actually tried that approach. I calculated the width of (a) and then > adjusted the width of the fringes accordingly. > > ,---- > | (let ((d (- (frame-pixel-width) > | (* (frame-width) > | (frame-char-width))))) > | (set-frame-parameter (selected-frame) 'left-fringe > | (/ d 2)) > | (set-frame-parameter (selected-frame) 'right-fringe > | (+ (/ d 2) (% d 2)))) > `---- > > The result were wider fringes but the "extra space" did not go away, it > just changed it's width. This cannot be done from Lisp, only from C. Sorry, I should have made myself clear. > > Echo area is harder, because it's just a window, so its size must > > currently be a multiple of the default font's size. Perhaps we could > > modify the mode-line width instead, by changing the line-with > > attribute of the mode-line face. Can you try that? > > Adjusting the mode-line height would very likely result in the same > problem as adjusting the fringe width. Maybe so, but did you actually try that? The display engine surprised me more than once. > > It should be clear that the device-independent stage _must_ produce a > > glyph for every character, even if that character is only partially > > visible. And since the number of glyphs is always integer, you get > > the limitation of the integral multiple of frame font's size. IOW, > > the issue here is _not_ that we cannot draw partially visible > > character -- we can -- but that the glyph matrix _dimensions_ must be > > integers. The current limitation exists because asking the wm to > > observe the same restrictions was the easiest way of reconciling an > > internal requirement of integer dimensions of the glyph matrices with > > the fact that GUI frames are drawn and sized in pixels. > > I understand why the width of the text area has to be an integer and am > aware that it partially visible characters can be drawn; and why that is > a good thing. Actually, the above was written in the hope to make clear that the width of the text area does _not_ have to be an integer number of frame font's width units. The dimensions of the glyph matrix must be inger, of course, but the last glyph can be only partially visible. IOW, the matrix dimensions should be computed as the round-up of the result of dividing the window width by the width of the default font. > >> From: James Cloos > >> Doesn't it just require not setting the .width_inc and .height_inc > >> members of the size_hints struct in src/xterm.c and src/gtkutil.c, > >> and editing the .min_width and .min_height code to account for that? > > > Maybe I'm missing something, but all your changes do is refrain from > > setting the width_inc and height_inc members of the XSizeHints > > structure. Can you explain how does this solve the problem? > > It seems that you think the above was written by the same person as the > original report. No, I don't think I did. (Why does that matter, anyway?) > I agree with you that all this does is to not provide size hints and > that as a result the display problems that are now limited to wms that > ignore size hints would instead affect all wms. OK, so we are in violent agreement.