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: Coordinates and Windows Date: Thu, 16 Jul 2015 17:32:38 +0300 Message-ID: <83bnfc6um1.fsf@gnu.org> References: <55A60508.7090903@gmx.at> <83oajd79kz.fsf@gnu.org> <55A6A4A1.1030307@gmx.at> <83fv4p6wqp.fsf@gnu.org> <55A759D1.5090001@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1437057169 27892 80.91.229.3 (16 Jul 2015 14:32:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jul 2015 14:32:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 16 16:32:41 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 1ZFkDI-0005gS-OA for ged-emacs-devel@m.gmane.org; Thu, 16 Jul 2015 16:32:40 +0200 Original-Received: from localhost ([::1]:40564 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFkDH-0002Jb-ST for ged-emacs-devel@m.gmane.org; Thu, 16 Jul 2015 10:32:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFkDD-0002Gx-DW for emacs-devel@gnu.org; Thu, 16 Jul 2015 10:32:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFkDA-0001fx-3x for emacs-devel@gnu.org; Thu, 16 Jul 2015 10:32:35 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:38717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFkD9-0001fi-NB for emacs-devel@gnu.org; Thu, 16 Jul 2015 10:32:32 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NRL00J004AO9C00@mtaout28.012.net.il> for emacs-devel@gnu.org; Thu, 16 Jul 2015 17:32:32 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NRL00C314E7I270@mtaout28.012.net.il>; Thu, 16 Jul 2015 17:32:32 +0300 (IDT) In-reply-to: <55A759D1.5090001@gmx.at> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 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:187900 Archived-At: > Date: Thu, 16 Jul 2015 09:14:25 +0200 > From: martin rudalics > CC: emacs-devel@gnu.org > > >> Currently we confuse the user. > > > > My suggestion attempts to remove that confusion, I think. > > We'd expect users (like we currently do on Windows, Lucid and Motif) to > care about tool bar dimensions when talking about window and frame > coordinates. Asking Gtk users to do the same would certainly not be met > with great enthusiasm (once such a change had been installed). 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? > >> I'm not sure yet. Coordinates on TTY frames are a separate issue, > >> functions like `window-pixel-edges' don't make too much sense there. > > > > They still should work, to avoid complications in applications. > > 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. > 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? > >> > And don't forget that some modes, like gdb-mi, simulate the tool bar > >> > below the menu bar on TTY frames -- what about those? > >> > >> But if I'm not mistaken neither of these are windows. > > > > No, but their glyph rows still have coordinates. > > Which implies that in order to build a glyph matrix we don't necessarily > need a window. So couldn't we do away with those pseudo-windows needed > for tool and menu bars? Not on GUI frames, no. On text-mode frames we have per-frame glyph matrices (and actually the glyph matrices of the windows are just slices of their frame's matrix). But on GUI frames, there's no frame glyph matrix, so you need a window to be able to draw anything. (And they are not pseudo-windows, btw; they are full-fledged windows, they just display stuff that comes from strings generated by the display engine, not from some buffer.) > >> So usually the root window top line must be rounded which I dislike > >> profoundly. With a toolbar on the left I would then have to round the > >> value of (window-left-column) on GTK as well. > > > > Why do we have to round, now that we have pixel-wise accuracy in > > resizing windows and frames? > > 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? > >> And then we would have still the problem that while for most builds we > >> do not include the menu bar, we would have to include it when we draw it > >> ourselves. So the problem would be only partly solved. > > > > The only cases I know of are the TTY and non-toolkit X. Are there any > > others? If not, these are special anyway, and could be handled > > separately. > > The non-toolkit X code is rather intertwingled with the non-GTK code so > we'd certainly had to provide lots more of special casing than we do > now. Most special casing will be hidden behind macros and small functions, so I see no particular problems here. Of course, I might be missing something. > To coherently apply your proposal we would have to put the origin > at the left upper corner of the menu bar - toolkit or not. Yes, that's the idea.