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

[Jan Djärv]

YAMAMOTO Mitsuharu skrev 2010-07-02 04.10:

> What do you think about the following point?
>
> > > > > > On Tue, 01 Jun 2010 10:16:08 +0900, YAMAMOTO 
> > > > > > Mitsuharu<mituharu@math.s.chiba-u.ac.jp>  said:
>
> > I'd rather suggest introducing some conversion functions between
> > relative and absolute coordinate systems.  Newer versions of Mac OS
> > X provides "Resolution Independence" that allows users to specify a
> > scale factor:
>
> >    
> > http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/HiDPIOverview/HiDPIConcepts/HiDPIConcepts.html
>
> > With the scale factor, 1 pixel in the relative coordinate system no
> > longer always correspond to 1 pixel in the absolute one.  Thus one
> > cannot determine the corresponding absolute coordinates only from
> > `inside-left' and `inside-top'.
>
> (Maybe "pixel" above should be "unit".)
>
> One can argue that the new API can return enough information to deal
> with the scale factor by computing width and height in both relative
> and absolute coordinate systems.  But I guess many programmers just
> tends to add some offsets for the conversion between these coordinate
> systems.  This might cause rewrite of elisp programs when GTK+
> supports resolution independence in future.

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?

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.

        Jan D.