bug#5721: Feature request: Function that returns absolute coordinates

["Jan Djärv" <jan.h.d@swipnet.se>]

YAMAMOTO Mitsuharu skrev 2010-07-15 08.49:
>
> It's the source of complication to divide absolute into scaled and
> unscaled (the latter is required anyway because window system APIs
> require that).  It's much simpler and cleaner to consider that
> absolute is alway unscaled and relative is always scaled.
>
>> Placing tooltips for example is much more common than placing
>> frames.  Doing so based on scaled coordinates is no problem.
>
> I don't understand how placement of tooltips and frames are different.
> The documentation of tooltip-frame-parameters says `left' and `top' is
> specified with absolute position.  Do you mean assigning different
> meanings to these frame parameters depending on whether it is for a
> tooltip or for a usual frame?

No, just that placing of tooltips is very common and just one of those things 
that does f->left_pos + some offset.

>
>> The alternative, to use unscaled, would make Emacs internals
>> everywhere have to handle two coordinate systems all the time.  To
>> knowingly introduce such an overhead on everything is madness.
>
> The Mac port already takes account of scaling factor with the policy I
> explained.  That means no change is necessary for the platform
> independent part.  The conversion is necessary only when the current
> X11 code is using the "idiom"s like `x += f->left_pos +
> FRAME_OUTER_TO_INNER_DIFF_X (f)'.

I think your "only" is quite big.  Lots of code, C and Lisp, does that kind of 
calculation.

	Jan D.