Re: Coordinates and Windows

[Eli Zaretskii]

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