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: Wed, 15 Jul 2015 22:34:22 +0300 Message-ID: <83fv4p6wqp.fsf@gnu.org> References: <55A60508.7090903@gmx.at> <83oajd79kz.fsf@gnu.org> <55A6A4A1.1030307@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1436988888 28492 80.91.229.3 (15 Jul 2015 19:34:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Jul 2015 19:34:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 15 21:34:40 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 1ZFSS0-0002qm-4q for ged-emacs-devel@m.gmane.org; Wed, 15 Jul 2015 21:34:40 +0200 Original-Received: from localhost ([::1]:37199 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFSRz-0000y4-DU for ged-emacs-devel@m.gmane.org; Wed, 15 Jul 2015 15:34:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFSRn-0000xx-2O for emacs-devel@gnu.org; Wed, 15 Jul 2015 15:34:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFSRi-0003wQ-RX for emacs-devel@gnu.org; Wed, 15 Jul 2015 15:34:26 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:55596) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFSRi-0003sK-6o for emacs-devel@gnu.org; Wed, 15 Jul 2015 15:34:22 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NRJ00600NBNE800@mtaout25.012.net.il> for emacs-devel@gnu.org; Wed, 15 Jul 2015 22:30:24 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NRJ004ECNINLY30@mtaout25.012.net.il>; Wed, 15 Jul 2015 22:30:24 +0300 (IDT) In-reply-to: <55A6A4A1.1030307@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.181 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:187886 Archived-At: > Date: Wed, 15 Jul 2015 20:21:21 +0200 > From: martin rudalics > CC: emacs-devel@gnu.org > > > This would mean the tool bar window (it is a real window drawn by > > Emacs in non-GTK builds) will yield negative frame-relative Y > > coordinates, won't it? > > Yes. And there might be even a menu bar window on top of it. Is there some configuration where the menu bar is a window? > > We didn't have such calamity until now, and > > even if it did work, it would be confusing, I think. > > Maybe. But coordinates inside the tool and menu bars are not exposed to > Lisp (IIUC) so the confusion would be restricted to the display engine > and the mouse handling routines. That's not something to dismiss, surely. > Currently we confuse the user. My suggestion attempts to remove that confusion, I think. > > Also, what about the menu bar, in particular on TTY frames? Will the > > screen estate used for the menu bar also have negative coordinates? > > 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. > > 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. > > Perhaps we should do it the other way around: make the coordinates in > > the GTK build be measured from the upper-left corner of the frame, > > including the tool bar? I think this will be more natural and easy to > > deal with. > > Here the toolbar window doesn't have an integral number of frame lines: > > (window-top-line) 3 > > while > > (window-pixel-top) gives 36 (with a character height of 16). > > 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? > 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.