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 09:14:25 +0200 Message-ID: <55A759D1.5090001@gmx.at> References: <55A60508.7090903@gmx.at> <83oajd79kz.fsf@gnu.org> <55A6A4A1.1030307@gmx.at> <83fv4p6wqp.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 1437030891 25609 80.91.229.3 (16 Jul 2015 07:14:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jul 2015 07:14:51 +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 09:14:43 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 1ZFdNS-0001OM-MI for ged-emacs-devel@m.gmane.org; Thu, 16 Jul 2015 09:14:42 +0200 Original-Received: from localhost ([::1]:38728 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFdNR-0005e6-Tu for ged-emacs-devel@m.gmane.org; Thu, 16 Jul 2015 03:14:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60064) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFdNO-0005e1-HF for emacs-devel@gnu.org; Thu, 16 Jul 2015 03:14:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFdNN-000871-4n for emacs-devel@gnu.org; Thu, 16 Jul 2015 03:14:38 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:62534) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFdNJ-000814-63; Thu, 16 Jul 2015 03:14:33 -0400 Original-Received: from [178.190.166.76] ([178.190.166.76]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MUUWN-1ZNZif3HgB-00RLou; Thu, 16 Jul 2015 09:14:30 +0200 In-Reply-To: <83fv4p6wqp.fsf@gnu.org> X-Provags-ID: V03:K0:RumkebiTMEhWNmqSzJDbIN/iJzcJAD8miYbBdeJLkqxEylizHUi HlL0SY31nxdrslgC1lCn+DIdqWydDvSSOGei9u8dTkvQcVvQl1HLmRHo3td07v6PeclJIRi 8ex/xaOCxi51LKltgQcFA2KefiGHxjTrwoTf3FueJ+GxrKx/qNA23Tl441TqhkHIIuLi2bh dNNKoYOz/WgG7BEHoBX4A== X-UI-Out-Filterresults: notjunk:1;V01:K0:RXe5iokxStc=:AbEBQZT6a3kmD1YgMSAaQL iTpJDuBrANzKclvRefiaUAe0Vk43z+Dypw+alcjXe1XBJykpQCCz8/LbVXg1jGytg9v6gdxBu zf6FCY7rSZVM7ZK+vyi+CBzsv7vJLqMU6JR85MtyDz0wmLhirESsyNzD4P1SGo9U3+ZiwiB+4 6P9WqUS1PL76zneW+stjFtYVs/3yfmb2/QHyKlXSoLxB8u2xQbpaubodgI/axknL2ueb+VY2u YUkq7j70bHCyNGe3zq2dm0oXvucfLtLv1uODVV8+9W1PggnZU7xrb4aeof9S/RPHpirLVTfTM U6FXvYwlrWO2DD9+oUG52iAqCIesgy466KnmwuTEpq4f3YoJ8raEvOAs7rZRoOiZldJFSFkxw fExhUzMAWASdeqg33tiAVeHXSVmwYnqglASf5I7k67dy3YGGkj5KTmSe6344oG558cbQLwnIP MkMaMXi4paqHFdewV9Hvo8Jq4RUEJunNc0xx+2CZejR8hT5Z+wpcsyGhdcCLuzMXE+CuO5RXz iUQ+yuiEh/JlTFCZHXM2mP8R5F+OeTG96oX2fFZGLlKR7w/kMDKrbLiIaYoUjqHXYRzaoxptg kEp1/Wy4n1KYcTukDJWzrC6JcUydDVJkpyy5dEQOedCvobyTwv4A33w4nb5I8aXKdVPUlcClk ebzytOef2t9LN/oHpFvv2BIT7rNLoTBLldHn9+e6ruZqmWbpil1S1XPi3ocblkzJOqAA= 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:187895 Archived-At: >> 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? In X builds without toolkit. >> 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. Right. >> 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'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. 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. >> > 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? >> 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. >> 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. To coherently apply your proposal we would have to put the origin at the left upper corner of the menu bar - toolkit or not. martin