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#19482: Changing to big font cause display problem Date: Wed, 25 Feb 2015 10:20:05 +0100 Message-ID: <54ED93C5.7020307@swipnet.se> References: <54DE424B.8070506@gmx.at> <7294F8DD-9324-4872-9AAA-5E4A229EFD04@icloud.com> <54E49C26.1070209@gmx.at> <0534A31D-5D69-4687-88CE-FA3C23A20278@icloud.com> <54E58941.3030005@gmx.at> <0255489D-9FE7-4C96-850D-2ED2FC80E42B@icloud.com> <54E77B3E.4000907@gmx.at> <1C7DF283-CB55-4360-AC5B-7565305D85F8@icloud.com> <54E86FA3.6010902@gmx.at> <54E9A8CB.8070605@gmx.at> <3EDF6985-A93A-46E9-9083-C2E496AB98C1@icloud.com> <24726EFE-F45F-4F6C-8941-AA1E5457D14F@swipnet.se> <54EA0D77.7010009@gmx.at> <504DD3FF-BA56-4407-AFE6-CCAA9F90BB31@swipnet.se> <54EA2570.8090504@gmx.at> <54EAC726.8090208@swipnet.se> <7F209FD7-19DD-4F47-A8BF-98E88EC65FCB@swipnet.se> <54ED7B0F.2070101@gmx.at> 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 1424856091 25130 80.91.229.3 (25 Feb 2015 09:21:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Feb 2015 09:21:31 +0000 (UTC) Cc: 19482@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 25 10:21:18 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 1YQY9e-0008WE-9T for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Feb 2015 10:21:18 +0100 Original-Received: from localhost ([::1]:53449 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQY9d-0007KF-P3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Feb 2015 04:21:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQY9U-0006zM-AI for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 04:21:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQY9O-00031J-NU for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 04:21:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQY9O-00031F-K8 for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 04:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YQY9O-0000XB-6I for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 04:21: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: Wed, 25 Feb 2015 09:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19482 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19482-submit@debbugs.gnu.org id=B19482.14248560231983 (code B ref 19482); Wed, 25 Feb 2015 09:21:02 +0000 Original-Received: (at 19482) by debbugs.gnu.org; 25 Feb 2015 09:20:23 +0000 Original-Received: from localhost ([127.0.0.1]:57297 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQY8k-0000Vu-1Y for submit@debbugs.gnu.org; Wed, 25 Feb 2015 04:20:22 -0500 Original-Received: from mailfe07.swip.net ([212.247.154.193]:60410 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQY8g-0000Vc-KV for 19482@debbugs.gnu.org; Wed, 25 Feb 2015 04:20:20 -0500 X-T2-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_20 Original-Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 574489875; Wed, 25 Feb 2015 10:20:09 +0100 Original-Received: from jdvpro.hq.ismobile.com (unknown [176.57.193.190]) (Authenticated sender: jhd) by hosdjarv.se (Postfix) with ESMTPSA id 6EC801A01E5; Wed, 25 Feb 2015 09:20:09 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 In-Reply-To: <54ED7B0F.2070101@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: 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:99791 Archived-At: martin rudalics skrev den 2015-02-25 08:34: > > It is a bug, popups will popup at the wrong position. We need to > track all four sides. > > I'm implementing that. > > Thanks. > > > But I still think you are confused about what is outer and inner > > window here. > > For the purpose of `x-frame-geometry' the outer window of a frame on X > is the one returned by FRAME_OUTER_WINDOW. The inner window is the one > whose size is given by FRAME_PIXEL_WIDTH and FRAME_PIXEL_HEIGHT. Then you should never need to bother with _OUTER_TO_INNER_DIFF. > `x-frame-geometry' should return in 'frame-outer-size' the size of the > _outer window_ including any external toolbar or menubar "attached to > that window" (I'm not interested in "floating" bars). This way, Emacs > can check whether the outer window fits conceptually into the working > area of its display. > > > In the macro OUTER_TO_INNER_DIFF outer refers to the > > window that the windowmanager puts as Emacs parent. "Inner" here is > > actually the outermost Emacs created X window, and "outer" is the > > window manager window. So outer contains the title bar, > > IIUC the only problem is whether the "window manager window" does > contain the external toolbar/mmenubar. It never does. It only contains the title bar. > The title bar and the external > borders are definitely part of the window manager window. The title bar is, but borders are not. It is entirely possible to set border on any X window, regardless of where it is in the hierarchy. So the external borders Emacs sets is on the outmost Emacs window, not on the window manager window. > > > but this: > > > > outer_width = FRAME_PIXEL_WIDTH (f) + 2 * border; > > outer_height = (FRAME_PIXEL_HEIGHT (f) > > + FRAME_OUTER_TO_INNER_DIFF_Y (f) > > + FRAME_OUTER_TO_INNER_DIFF_X (f)); > > > > > > is just plain wrong, because for you are calculating something that > > does not correspond to any real window. For example, on Gnome 3 the > > window manager puts in a window that is 10 pixels wider on both sides, > > so it can do shadow effects. But the border is still one or zero > > pixels. > > FRAME_OUTER_TO_INNER_DIFF_Y gives me only the offset of the top left > corner, that is, the difference of the top edge of the outer window and > the inner window. You must specify what you mean by outer and inner. FRAME_OUTER_TO_INNER_DIFF_Y gives the diff between the outmost Emacs created window and the window manager window. > I don't know how to get the difference between the > bottom edge of the Emacs window and the bottom edge of the outer window. > So I approximate. This approximation obviously goes wrong when the left > and bottom borders are not the same size. Can you tell me a better way? As I said, I'm implementing this. But it seems you don't need this. If you are only interested in the size of the Emacs created outmost window, OUTER_TO_INNER_DIFF does not apply. Only borders do. > > > So what you have calculated is not the window manager window sizes, > > because inner_to_outer width is not taken into account. > > FRAME_OUTER_TO_INNER_DIFF_X gives me the offset of the left edge of the > inner window wrt the outer window. Again, define inner and outer. We are using confusing terminology. I suggest window manager window Outmost Emacs created window. Inner Emacs created window. > The only thing I can do is multiply > it by two. As mentioned earlier, if these differences are not > symmetric, for example, because one border is larger than the other, the > information provided is wrong. Again, it's the best approximation I can > come up with so far. > > > There > > actually is no window with width FRAME_PIXEL_WIDTH + 2 * border in the > > Gnome 3 case. > > Are you sure? Does FRAME_OUTER_TO_INNER_DIFF_X not include the extra 10 > pixels you mentioned above? Yes they do. > > > For Gtk+/Motif/Lucid, we create a window outside the > > frame (i.e. text editing part) that contains the tool bar if external, > > menu bar and scroll bar. But that window is not this size either, the > > width would in general contain the scroll bar for example. > > That would be devastating. Scroll bars are part of the inner window. Not in the X sense, they are attached to the outmost Emacs created window. Thats one of the reasons we have that window, the other is external menubar and external tool bar. Only Emacs native scrollbar are attached to the inner Emacs window, as well as non-external (i.e. text) menu and non-external toolbar. > > > So what are you trying to calculate? Is it the window manager window > > geometry, or the geometry of the largest Emacs created window? > > The sizes of the outer window aka window manager window. The size of > the largest Emacs created window is returned by `x-frame-geometry' for > comparison purpose only (via 'frame-inner-size'). But for frame-inner-size you subtract menu and tool bar. So this is not the size of the largest Emacs created window. What are you doing with these sizes? Jan D.