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

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Fri, 02 Jul 2010 09:06:49 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

> One could argue that we are always dealing with scaled pixels, and
> absolute in this context means "absolute scaled" instead of
> "absolute unscaled".  Can't we always use scaled coordinates?  When
> do we need to handle unscsaled?

I think major motivation to use the absolute coordinate system is to
specify the frame location (OP's case), or to pass it to external
programs (the SCIM case).  "Absolute unscaled" one is more suitable
for such uses.

> The new functions use tool bar and title bar height as well as frame
> top and left.  Are these scaled or unscaled pixels?  Shouldn't the
> nextstep specific code just expose scaled pixels to the generic code
> and do the conversion when needed?  I know too little about which
> API functions that use scaled and which use unscaled.

I've never cared about the tool bar and title bar height in the Mac
port because its explicit computation is unnecessary in Cocoa:
conversions between multiple coordinate systems (for views, windows,
and the screen) are provided as NSView/NSWindow methods. Sometimes
simple translation by offsets is not sufficient for these conversions:
it may involve flipping or scaling.

http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/HiDPIOverview/HiDPISupport/HiDPISupport.html

Using them, we could minimize the code change even if we changed the
position/scale of the view for Emacs frame relative to the enclosing
window.


				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp