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: Wed, 15 Jul 2015 20:21:21 +0200 Message-ID: <55A6A4A1.1030307@gmx.at> References: <55A60508.7090903@gmx.at> <83oajd79kz.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 1436984513 20984 80.91.229.3 (15 Jul 2015 18:21:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Jul 2015 18:21:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 15 20:21:44 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 1ZFRJQ-0004iM-11 for ged-emacs-devel@m.gmane.org; Wed, 15 Jul 2015 20:21:44 +0200 Original-Received: from localhost ([::1]:36990 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFRJP-0007zt-C5 for ged-emacs-devel@m.gmane.org; Wed, 15 Jul 2015 14:21:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33509) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFRJD-0007zc-JX for emacs-devel@gnu.org; Wed, 15 Jul 2015 14:21:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFRJA-0002nU-Bm for emacs-devel@gnu.org; Wed, 15 Jul 2015 14:21:31 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:58311) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFRJA-0002nM-3W; Wed, 15 Jul 2015 14:21:28 -0400 Original-Received: from [88.117.81.209] ([88.117.81.209]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MI8iw-1ZFzo03ugQ-003v2z; Wed, 15 Jul 2015 20:21:27 +0200 In-Reply-To: <83oajd79kz.fsf@gnu.org> X-Provags-ID: V03:K0:4/r/XH8YT151/InFbUeOeLDVOER+0CGcm9KhnZWtXzlZLDPAJaN zQF3XI/5mC55Frmkk+bofu+Z+6nYANuw9xSbfXgRs7OO6n2HulFWUrADd7KRe+HnNj+892Z mxJ7FW2YmnIIBWKBmiJrWSHUxAOlaM+SjEDbETKRQx/Z2/Ekr6gzLBGvzoKjlEOzdIQ1GJu YFacS8JlHeHV43I3gCwHQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Sc0nwuFC6/s=:9dC9YRNQCrDKzgxdJTM5KC WONkwTexnPINGZpPiseaFqkJ5/7O+gEannCo3Sje9U+As6gwaZFgahzprffzoioG34wwwOljS DJX7Sh6r1EPedqgpFq52ehdcfwePvXstIed4WgNjtk6klZeUtqheRjS8tFkO+EVopJG2s6n3W vjrrIbxC3orcpvt+EIcFUKU5oJBiN0CVvsBm27Mx4JgOd1c3IBc5SCe1KXN+0C3+kXysfA/Pl 6G5UUiNezUfx1WM/O0jwYF7HavHCPEDw/CekPiJOLjM0DPvkdoGWtuZcfMqwqEnHJIS2ZfC/e ZnFviXJmuU4vcvNAnDr3S8dl0RsF6frH/YQ8Gu+dyFs2lP11Fw7Z90ku9jOeUYJ/OjkfN5Nc1 Semoe5Z25s4FRkPhgFIhz6lwxtpovU2Jv1sn/gP/SUjyHUbB5V++Cj+IVsJgzhjjKH6rFm+dQ xFLJymRWF5XtqUekEdaScwOmINfSEPoT6Uf2RtDQk6N9Co+S61J6TBp+xwJUDegPMG+Wv0U7i 0bI3jUqHJv1cv/5lzqjduBqNXP78hP6X2wFgGdKWDxe0m27hvq/BivKF8yJe999XoLe9J8TcX xyCyQ5gkOCMzOCgfw7BBeC7QgZkYC8yyk3pNXdNgTrd8pHtPonyK5e5Vconi3G+eAsMkZo3wG t5xQuMMSk9sLfH+KwslwVFA+KFJKo3RsOBglxUenLp5U5yLbDYhxikgBKBKJCAToRVw4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.17.22 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:187885 Archived-At: > 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. > 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. Currently we confuse the user. Note also that the internal border is drawn between tool bar and root window. This means that windows already do not form a contiguous region for a number of builds which is confusing too. > 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. > 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. > 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. 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. martin