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