Coordinates and Windows

Coordinates and Windows

[martin rudalics]

Section 27.24 of the Elisp manual contains the following description:


Coordinates and Windows

This section describes functions that report the position of a window.
Most of these functions report positions relative to the window's
frame.  In this case, the coordinate origin `(0,0)' lies near the upper
left corner of the frame.  For technical reasons, on graphical displays
the origin is not located at the exact corner of the graphical window
as it appears on the screen.  If Emacs is built with the GTK+ toolkit,
the origin is at the upper left corner of the frame area used for
displaying Emacs windows, below the title-bar, GTK+ menu bar, and tool
bar (since these are drawn by the window manager and/or GTK+, not by
Emacs).  But if Emacs is not built with GTK+, the origin is at the
upper left corner of the tool bar (since in this case Emacs itself
draws the tool bar).  In both cases, the X and Y coordinates increase
rightward and downward respectively.


My intention is to remove this difference and make the "coordinate
origin" for all systems the top/left corner of the root window of the
respective frame.  Practically, this is what the GTK+ build does now.

I'm not yet sure whether this is feasible and whether there will be any
difficulties.  Anyway, if you see problems or have any objections please
tell me now.

Thanks, martin

Re: Coordinates and Windows

[Eli Zaretskii]

> Date: Wed, 15 Jul 2015 09:00:24 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
> My intention is to remove this difference and make the "coordinate
> origin" for all systems the top/left corner of the root window of the
> respective frame.  Practically, this is what the GTK+ build does now.

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?  We didn't have such calamity until now, and
even if it did work, it would be confusing, 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?

And don't forget that some modes, like gdb-mi, simulate the tool bar
below the menu bar on TTY frames -- what about those?

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.

Re: Coordinates and Windows

[martin rudalics]

 > 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

Re: Coordinates and Windows

[Eli Zaretskii]

> Date: Wed, 15 Jul 2015 20:21:21 +0200
> From: martin rudalics <rudalics@gmx.at>
> 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.

Re: Coordinates and Windows

[martin rudalics]

 >> 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

Re: Coordinates and Windows

[Eli Zaretskii]

> Date: Thu, 16 Jul 2015 09:14:25 +0200
> From: martin rudalics <rudalics@gmx.at>
> 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.

Re: Coordinates and Windows

[martin rudalics]

 > 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?

If by top-left corner you intend the top-left position of the menu bar,
or if that's absent that of the top/left tool bar, or if that's absent
too that of the internal border, or if that is absent too that of the
root window, I agree.  Just that it's not all too trivial to calculate
it.

We know the size of the tool bar only after we have displayed it.  This
is already a problem on Lucid, Motif, Windows.  And Windows has certain
difficulties telling us the height of the menubar when it wraps.  This
too is already a problem, so nothing new here.  But there might be yet
unknown problems with Gtk and NS.

 >> 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.

Just 32 pixels for title, menu, and tool bar?  Here `x-frame-geometry'
tells me that they alone take 74 pixels.  BTW, has Windows 7 an 8 pixel
wide border by default?

 >> 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?

No, off-screen decorations are a Windows feature.  What I meant is that
Gtk has some established, working features that albeit never worked on
Windows.  And I'm afraid to break these features.

 >> 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?

The windmove code, for example, determined adjacency of windows from the
fact that their respective edges matched.  It took me some time to
adjust the line/column calculation code to handle that in an artificial
way.  I don't know how much code exists that uses similar heuristics.

martin

Re: Coordinates and Windows

[Eli Zaretskii]

> Date: Thu, 16 Jul 2015 20:23:06 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > 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?
> 
> If by top-left corner you intend the top-left position of the menu bar,
> or if that's absent that of the top/left tool bar, or if that's absent
> too that of the internal border, or if that is absent too that of the
> root window

Yes.

> I agree.  Just that it's not all too trivial to calculate it.

In pixels or in rows?

>  >> 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.
> 
> Just 32 pixels for title, menu, and tool bar?

Maybe I'm confused, but doesn't that include only the title and menu
on Windows?  Or maybe just the title?

> BTW, has Windows 7 an 8 pixel wide border by default?

How can I know?

> No, off-screen decorations are a Windows feature.  What I meant is that
> Gtk has some established, working features that albeit never worked on
> Windows.  And I'm afraid to break these features.

Isn't that what development is about -- breaking features and then
fixing the breakage?

Re: Coordinates and Windows

[martin rudalics]

 >> I agree.  Just that it's not all too trivial to calculate it.
 >
 > In pixels or in rows?

In pixels.

 >> Just 32 pixels for title, menu, and tool bar?
 >
 > Maybe I'm confused, but doesn't that include only the title and menu
 > on Windows?  Or maybe just the title?

This would imply that the tool bar (and maybe even the menu bar) are
part of the root window.  But don't worry.  On GTK we don't count the
title bar either.  The only platform where this might work is NS ;-)

 >> BTW, has Windows 7 an 8 pixel wide border by default?
 >
 > How can I know?

What does M-: (x-frame-geometry) give for you?

 > Isn't that what development is about -- breaking features and then
 > fixing the breakage?

 From your lips to God's ears.

martin

Re: Coordinates and Windows

[Eli Zaretskii]

> Date: Fri, 17 Jul 2015 15:36:08 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  >> I agree.  Just that it's not all too trivial to calculate it.
>  >
>  > In pixels or in rows?
> 
> In pixels.

Why does it matter if we get that accurately, in builds where we don't
manage those decorations?  We might as well approximate that with some
reasonable value, and be done, no?

>  >> Just 32 pixels for title, menu, and tool bar?
>  >
>  > Maybe I'm confused, but doesn't that include only the title and menu
>  > on Windows?  Or maybe just the title?
> 
> This would imply that the tool bar (and maybe even the menu bar) are
> part of the root window.

Which on Windows, it is, AFAIK.

>  >> BTW, has Windows 7 an 8 pixel wide border by default?
>  >
>  > How can I know?
> 
> What does M-: (x-frame-geometry) give for you?

This is on XP:

  ((frame-position -4 . -4) (frame-outer-size 1928 . 1088) (external-border-size 4 . 4) (title-height . 19) (menu-bar-external . t) (menu-bar-size 1920 . 19) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 1920 . 36) (frame-inner-size 1920 . 1042))

RE: Coordinates and Windows

[Drew Adams]

> > What does M-: (x-frame-geometry) give for you?
> 
> This is on XP:
> 
>   ((frame-position -4 . -4) (frame-outer-size 1928 . 1088) (external-border-
> size 4 . 4) (title-height . 19) (menu-bar-external . t) (menu-bar-size 1920
> . 19) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 1920 .
> 36) (frame-inner-size 1920 . 1042))

And on Windows 7, for emacs -Q:

((frame-position 78 . 78) (frame-outer-size 845 . 793) (external-border-size 4 . 4) (title-height . 23) (menu-bar-external . t) (menu-bar-size 837 . 25) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 837 . 37) (frame-inner-size 837 . 737))

with this build:

In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2015-07-03 on LEG570
Repository revision: 2b848fadd51e805b2f46da64c5958ea7f009048a
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --host=i686-pc-mingw32 --enable-checking=yes,glyphs'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Messages

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Re: Coordinates and Windows

[martin rudalics]

 > Why does it matter if we get that accurately, in builds where we don't
 > manage those decorations?  We might as well approximate that with some
 > reasonable value, and be done, no?

For example, on Windows I need accurate dimensions of decorations to
emulate fullheight and fullwidth fullscreen modes.  And if I want to
display a tooltip at a certain position within a window I need them as
well.

 >> This would imply that the tool bar (and maybe even the menu bar) are
 >> part of the root window.
 >
 > Which on Windows, it is, AFAIK.

No.  The root window is beneath the tool bar window separated from the
latter by the internal border.

 >>   >> BTW, has Windows 7 an 8 pixel wide border by default?
 >>   >
 >>   > How can I know?
 >>
 >> What does M-: (x-frame-geometry) give for you?
 >
 > This is on XP:
 >
 >    ((frame-position -4 . -4) (frame-outer-size 1928 . 1088) (external-border-size 4 . 4) (title-height . 19) (menu-bar-external . t) (menu-bar-size 1920 . 19) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 1920 . 36) (frame-inner-size 1920 . 1042))

This doesn't help me to find out why your `window-absolute-pixel-edges'
returns (-8 28 1912 984) on Windows 7.  I need your value for Windows 7.

martin

Re: Coordinates and Windows

[martin rudalics]

 > And on Windows 7, for emacs -Q:
 >
 > ((frame-position 78 . 78) (frame-outer-size 845 . 793)
 > (external-border-size 4 . 4) (title-height . 23) (menu-bar-external
 > . t) (menu-bar-size 837 . 25) (tool-bar-external) (tool-bar-position
 > . top) (tool-bar-size 837 . 37) (frame-inner-size 837 . 737))

Thanks.  That's comparable to what I see here on XP.  What do you get
for a maximized frame?  And what does `window-absolute-pixel-edges'
return for the single window of a maximized frame?

martin

Re: Coordinates and Windows

[Eli Zaretskii]

> Date: Fri, 17 Jul 2015 19:58:12 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > Why does it matter if we get that accurately, in builds where we don't
>  > manage those decorations?  We might as well approximate that with some
>  > reasonable value, and be done, no?
> 
> For example, on Windows I need accurate dimensions of decorations to
> emulate fullheight and fullwidth fullscreen modes.

What do you mean by "emulate"?  AFAIK, these are supported on Windows
without any need for emulation.

> And if I want to display a tooltip at a certain position within a
> window I need them as well.

Why do you need _frame_ relative coordinates to display something at
_window_ relative position?

>  >> This would imply that the tool bar (and maybe even the menu bar) are
>  >> part of the root window.
>  >
>  > Which on Windows, it is, AFAIK.
> 
> No.  The root window is beneath the tool bar window separated from the
> latter by the internal border.

Strange.

>  >>   >> BTW, has Windows 7 an 8 pixel wide border by default?
>  >>   >
>  >>   > How can I know?
>  >>
>  >> What does M-: (x-frame-geometry) give for you?
>  >
>  > This is on XP:
>  >
>  >    ((frame-position -4 . -4) (frame-outer-size 1928 . 1088) (external-border-size 4 . 4) (title-height . 19) (menu-bar-external . t) (menu-bar-size 1920 . 19) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 1920 . 36) (frame-inner-size 1920 . 1042))
> 
> This doesn't help me to find out why your `window-absolute-pixel-edges'
> returns (-8 28 1912 984) on Windows 7.  I need your value for Windows 7.

Will report when I have a chance.

RE: Coordinates and Windows

[Drew Adams]

>  > And on Windows 7, for emacs -Q:
>  >
>  > ((frame-position 78 . 78) (frame-outer-size 845 . 793)
>  > (external-border-size 4 . 4) (title-height . 23) (menu-bar-external
>  > . t) (menu-bar-size 837 . 25) (tool-bar-external) (tool-bar-position
>  > . top) (tool-bar-size 837 . 37) (frame-inner-size 837 . 737))
> 
> Thanks.  That's comparable to what I see here on XP.  What do you get
> for a maximized frame?  And what does `window-absolute-pixel-edges'
> return for the single window of a maximized frame?

`(x-frame-geometry)':
((frame-position -4 . -4) (frame-outer-size 1928 . 1054) (external-border-size 4 . 4) (title-height . 23) (menu-bar-external . t) (menu-bar-size 1920 . 25) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 1920 . 37) (frame-inner-size 1920 . 998))

`(window-absolute-pixel-edges)': (-4 33 1916 974)

Re: Coordinates and Windows

[martin rudalics]

 >> For example, on Windows I need accurate dimensions of decorations to
 >> emulate fullheight and fullwidth fullscreen modes.
 >
 > What do you mean by "emulate"?  AFAIK, these are supported on Windows
 > without any need for emulation.

The Windows API knows only minimized and maximized frames.  The
fullboth, fullheight and fullwidth ones must be emulated.  I read that
Aero Snap provides a similar service but to my knowledge we can't call
that from within Emacs.  Also there was a bug report (by Juanma IIRC)
that we don't support some Snap feature(s) yet.

Just to explain what emulation means in this context: When a user sets
the `fullscreen' parameter to `maximized' we send a maximize request to
the OS, the latter calculates the coordinates and calls us back with the
new coordiantes.  When a user sets the `fullscreen' parameter to
`fullheight', Emacs calculates the new coordinates and sends a resize
request to the OS.  The OS has no idea that our frame is "full height".

 > Why do you need _frame_ relative coordinates to display something at
 > _window_ relative position?

Because currently `window-absolute-pixel-edges' is not accurate.  I use
a three steps translation process:

(1) `pos-visible-in-window-p' gets me "pixel coordinates relative to the
     top left corner of the window".

(2) I add the offsets of the window within its frame.

(3) I add the offsets of the frame on the display.

But the frame offsets I get via the `left' and `top' frame parameters in
(3) are those of the "outer frame" as placed by the window manager.
Hence in (2) the offsets provided, for example, by `window-pixel-edges'
as "relative to 0, 0 at the top left corner of the frame" are
insufficient because that corner is not the one from (3).

 >> No.  The root window is beneath the tool bar window separated from the
 >> latter by the internal border.
 >
 > Strange.

In a session where you never split windows, the root window is always
the one you see and work in.  Also, the minibuffer window, if it exists,
is beneath the root window unless your frame is a "minibuffer-only" one.

martin

Re: Coordinates and Windows

[martin rudalics]

 > `(x-frame-geometry)':
 > ((frame-position -4 . -4) (frame-outer-size 1928 . 1054) (external-border-size 4 . 4) (title-height . 23) (menu-bar-external . t) (menu-bar-size 1920 . 25) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 1920 . 37) (frame-inner-size 1920 . 998))
 >
 > `(window-absolute-pixel-edges)': (-4 33 1916 974)

Thanks.  That makes sense.  I wonder where Eli got his -8 from.

martin

Re: Coordinates and Windows

[Eli Zaretskii]

> Date: Sat, 18 Jul 2015 11:03:35 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > `(x-frame-geometry)':
>  > ((frame-position -4 . -4) (frame-outer-size 1928 . 1054) (external-border-size 4 . 4) (title-height . 23) (menu-bar-external . t) (menu-bar-size 1920 . 25) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 1920 . 37) (frame-inner-size 1920 . 998))
>  >
>  > `(window-absolute-pixel-edges)': (-4 33 1916 974)
> 
> Thanks.  That makes sense.  I wonder where Eli got his -8 from.

This is the result of x-frame-geometry for a maximized frame on
Windows 7, as requested and promised:

  ((frame-position -8 . -8) (frame-outer-size 1936 . 1066) (external-border-size 8 . 8) (title-height . 22) (menu-bar-external . t) (menu-bar-size 1920 . 20) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 1920 . 36) (frame-inner-size 1920 . 1008))

Re: Coordinates and Windows

[martin rudalics]

 > This is the result of x-frame-geometry for a maximized frame on
 > Windows 7, as requested and promised:
 >

 > ((frame-position -8 . -8) (frame-outer-size 1936 . 1066)
 >  (external-border-size 8 . 8) (title-height . 22) (menu-bar-external
 >  . t) (menu-bar-size 1920 . 20) (tool-bar-external) (tool-bar-position
 >  . top) (tool-bar-size 1920 . 36) (frame-inner-size 1920 . 1008))

Thanks.  Together with your earlier (-8 28 1912 984) as return value of
`window-absolute-pixel-edges' this makes sense now.  The latter adds the
top of the outer frame (-8) to the height of the internal tool bar (36)
disregarding any borders, title and menu bar.  The correct top-y value
in your case would be 78 (+ -8 8 22 20 36).

martin

Re: Coordinates and Windows

[martin rudalics]

 >> 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.)

If they are not pseudo-windows then why do they have the pseudo_window_p
flag get set in adjust_frame_glyphs_for_window_redisplay?

martin

Re: Coordinates and Windows

[Eli Zaretskii]

> Date: Mon, 20 Jul 2015 09:04:50 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > (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.)
> 
> If they are not pseudo-windows then why do they have the pseudo_window_p
> flag get set in adjust_frame_glyphs_for_window_redisplay?

I guess I misunderstood what you meant by "pseudo-windows".  If you
meant that flag, then yes, they are; but as you know, that flag is
used for variety of indications, like to avoid drawing the fringes and
the cursor in these windows, so "pseudo" here is a kind of misnomer,
IMO.