From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Coordinates and Windows
Date: Thu, 16 Jul 2015 09:14:25 +0200 [thread overview]
Message-ID: <55A759D1.5090001@gmx.at> (raw)
In-Reply-To: <83fv4p6wqp.fsf@gnu.org>
>> 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
next prev parent reply other threads:[~2015-07-16 7:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-15 7:00 Coordinates and Windows martin rudalics
2015-07-15 14:57 ` Eli Zaretskii
2015-07-15 18:21 ` martin rudalics
2015-07-15 19:34 ` Eli Zaretskii
2015-07-16 7:14 ` martin rudalics [this message]
2015-07-16 14:32 ` Eli Zaretskii
2015-07-16 18:23 ` martin rudalics
2015-07-17 13:09 ` Eli Zaretskii
2015-07-17 13:36 ` martin rudalics
2015-07-17 14:21 ` Eli Zaretskii
2015-07-17 17:58 ` martin rudalics
2015-07-17 18:10 ` Eli Zaretskii
2015-07-18 9:03 ` martin rudalics
[not found] ` <<83wpxy6f0x.fsf@gnu.org>
2015-07-17 15:09 ` Drew Adams
2015-07-17 17:58 ` martin rudalics
2015-07-17 19:28 ` Drew Adams
2015-07-18 9:03 ` martin rudalics
2015-07-19 16:47 ` Eli Zaretskii
2015-07-20 6:42 ` martin rudalics
2015-07-20 7:04 ` martin rudalics
2015-07-20 16:15 ` Eli Zaretskii
[not found] <"<83oajd79kz.fsf"@gnu.org>
[not found] ` <"<83fv4p6wqp.fsf"@gnu.org>
[not found] ` <"<83bnfc6um1.fsf"@gnu.org>
[not found] <<55A60508.7090903@gmx.at>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55A759D1.5090001@gmx.at \
--to=rudalics@gmx.at \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.