From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Coordinates and Windows Date: Thu, 16 Jul 2015 20:23:06 +0200 Message-ID: <55A7F68A.3040003@gmx.at> References: <55A60508.7090903@gmx.at> <83oajd79kz.fsf@gnu.org> <55A6A4A1.1030307@gmx.at> <83fv4p6wqp.fsf@gnu.org> <55A759D1.5090001@gmx.at> <83bnfc6um1.fsf@gnu.org> 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 1437071019 1671 80.91.229.3 (16 Jul 2015 18:23:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jul 2015 18:23:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 16 20:23:26 2015 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 1ZFnoc-00066m-EF for ged-emacs-devel@m.gmane.org; Thu, 16 Jul 2015 20:23:26 +0200 Original-Received: from localhost ([::1]:41444 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFnob-0005xP-Ih for ged-emacs-devel@m.gmane.org; Thu, 16 Jul 2015 14:23:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFnoX-0005xF-2j for emacs-devel@gnu.org; Thu, 16 Jul 2015 14:23:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFnoV-0003M7-Ud for emacs-devel@gnu.org; Thu, 16 Jul 2015 14:23:21 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:64708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFnoQ-0003KA-6F; Thu, 16 Jul 2015 14:23:14 -0400 Original-Received: from [93.82.13.78] ([93.82.13.78]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LhTjQ-1Yc11F0rzM-00mfYG; Thu, 16 Jul 2015 20:23:13 +0200 In-Reply-To: <83bnfc6um1.fsf@gnu.org> X-Provags-ID: V03:K0:Gmyeyr6ZZJuNASuddyng7oxrn/9q7BwDIqcB4QaNUr70nPwoT6O d99A3m0WB0zWIIBxfHX8B/4lCpC5LbCfbsZ5fTKPVSVngPDG/v7zAixXKYA3mFPNOrf2iYX 1JCuqk7SCwWhpmEl90pgB3ohdfznjpVnhL2Piuh3ICK6xgXhKiwK6281OA6U8YBadaV+Vq2 dAH7Yk6rwt8NKLSMBRqgw== X-UI-Out-Filterresults: notjunk:1;V01:K0:SEym0lRkjDQ=:TZ1+JntarvjfALPqbLo+8T PvzUwJW+dYqYt/Ftf2TkMjyJ/nZYMiKpyrpQXVaW4Eqm/XKVzKzAlLGV4TkDCnw/pks8J1Ha6 vDjvSy3bdOBtprNfSHuq+sKIxeckvh2nnE6yci7MUU1s80B3TlZSC1UMRE/oS50xB7Q8JqFc9 CUN92jRf0hsdL7PpOh7uwWGnY8BL9h1U/KqwKBjnC43rRIHgNA9PQzdI6TWOfHNzJXx+/Wn4u BM3H5MmlXc9UKitkZVWMX8B5Gv/Ibf8KCDSe1+ANKAjziXREsKBo+Ht0z3o3iYtjG+UaohEal 47Zfl9K8efyvmKVFOUg7fYkLyfjckol9AsW0VGBX8XBKw8sfcs7z31j0xfuIB/tLdS/An3bhe xPiqf+lET4xSWucdHdA1Gm+ZuvyTo5UaTP2yaJ5udW0tgVi4QmEu2uNWf9ulDQYpCLZqwOOOc bG8Tf1sBhuwBm04Uv9KgTRXfwJdSPJfhOr8y4re9wiqsZkDxur8of7Pcj8goBLnILS2W+GjX1 Xd7l6YTaTELrCizHuKJTJZPC7GPyW7ePUwfojoqD3/Z6GHf3Bleaa856CnQ85ohkf51nmrR8a qoqzW7HHZao+s2XgVfEkFxDRbUN/hWgfWaJQGF4ImQERFr12PEVcV3I8Sxpq8cp7ey0cnGrPX oeBY7VMUhTr/5+NQveybCtNkAhmelQUwm5ILFO40yBYbFtc9JKszjcW+ulyw44+aRpNY= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.17.20 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:187908 Archived-At: > I don't see why. Having the top-left corner of the frame as the > reference point sounds simpler and more clear to me, and allows one to > use it in the same way in all the builds. No? If by top-left corner you intend the top-left position of the menu bar, or if that's absent that of the top/left tool bar, or if that's absent too that of the internal border, or if that is absent too that of the root window, I agree. Just that it's not all too trivial to calculate it. We know the size of the tool bar only after we have displayed it. This is already a problem on Lucid, Motif, Windows. And Windows has certain difficulties telling us the height of the menubar when it wraps. This too is already a problem, so nothing new here. But there might be yet unknown problems with Gtk and NS. >> Actually, I started to look into this when I detected that it's >> virtually impossible to position a tooltip frame via `x-show-tip' at a >> window position obtained via `pos-visible-in-window-p' consistently on >> all platforms. >> >> To illustrate how little care has been applied to this so far, consider >> the function `window-absolute-pixel-edges'. With a maximized frame on >> Windows XP this function returns (-4 -4 1676 964) here. > > I get (-8 28 1912 984) on Windows 7 and (-4 32 1916 1022) on XP, so at > least the Y coordinate seems OK. Just 32 pixels for title, menu, and tool bar? Here `x-frame-geometry' tells me that they alone take 74 pixels. BTW, has Windows 7 an 8 pixel wide border by default? >> Apparently, this was designed for Gtk users, never really tested on >> other platforms. But this also implies that changing things for Gtk >> might not be a good idea. > > I don't follow the logic, can you elaborate why this implies what you > think it implies? Are you saying that on GTK a maximized frame has > some of its GTK decorations off-screen? No, off-screen decorations are a Windows feature. What I meant is that Gtk has some established, working features that albeit never worked on Windows. And I'm afraid to break these features. >> Because most programmers think (and applications work) in terms of rows >> and columns. `window-edges' is still quite in use although it's bound >> to provide inaccurate results in many occasions now. > > I'm afraid I still don't see why this requires rounding, especially if > the results are already inaccurate. E.g., can we consider the menu > bar a single line, and the tool bar another N lines (N is usually 1, > but doesn't have to be). IOW, can we treat each "row" of display in > these windows as a single line, for the purposes of counting rows? If > not, why not? The windmove code, for example, determined adjacency of windows from the fact that their respective edges matched. It took me some time to adjust the line/column calculation code to handle that in an artificial way. I don't know how much code exists that uses similar heuristics. martin