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 #61 received at 5721 <at> debbugs.gnu.org (full text, mbox):

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




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.