GNU bug report logs - #5721
Feature request: Function that returns absolute coordinates

Previous Next

Package: emacs;

Reported by: irieshinsuke <at> yahoo.co.jp

Date: Mon, 15 Mar 2010 14:34:02 UTC

Severity: wishlist

Done: Jan Djärv <jan.h.d <at> swipnet.se>

Bug is archived. No further changes may be made.

Full log


Message #58 received at 5721 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 5721 <at> debbugs.gnu.org, IRIE Shinsuke <irieshinsuke <at> yahoo.co.jp>
Subject: Re: bug#5721: Feature request: Function that returns absolute
	coordinates
Date: Fri, 02 Jul 2010 09:06:49 +0200

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 <at> 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.






This bug report was last modified 11 years and 239 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.