From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 15 10:33:13 2010 Received: (at submit) by debbugs.gnu.org; 15 Mar 2010 14:33:13 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NrBM0-0004BU-UY for submit@debbugs.gnu.org; Mon, 15 Mar 2010 10:33:13 -0400 Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NrBLx-0004BP-F4 for submit@debbugs.gnu.org; Mon, 15 Mar 2010 10:33:11 -0400 Received: from lists.gnu.org ([199.232.76.165]:49843) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NrBLs-0001rg-G7 for submit@debbugs.gnu.org; Mon, 15 Mar 2010 10:33:04 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NrBLr-0005lP-Q0 for bug-gnu-emacs@gnu.org; Mon, 15 Mar 2010 10:33:03 -0400 Received: from [140.186.70.92] (port=41149 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NrBLp-0005je-99 for bug-gnu-emacs@gnu.org; Mon, 15 Mar 2010 10:33:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,T_DKIM_INVALID,T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.0 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NrBLn-0003DE-Ke for bug-gnu-emacs@gnu.org; Mon, 15 Mar 2010 10:33:01 -0400 Received: from mail-fx0-f210.google.com ([209.85.220.210]:61115) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NrBLn-0003D0-Ej for bug-gnu-emacs@gnu.org; Mon, 15 Mar 2010 10:32:59 -0400 Received: by fxm2 with SMTP id 2so359058fxm.26 for ; Mon, 15 Mar 2010 07:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:subject:x-enigmail-version :content-type:content-transfer-encoding; bh=BWSGIAsRaSfKC/rq512rU360DjuAxpMoE6HELIQ8KNo=; b=QWgz6R9mdsNb8S4BNY/SjX9soLBJTNxwej8AOeumm779XQlDevPICmUgVIQkI/QDyC dydUb3H4D5xn7Svsu0v45Y6lo8s7OA2p6Q1RRyZihtZ7fFKsfhc8AvMMhUAt7SJ5oAEo 8PLxQnsyPkgcrg/focynoW0KLXJfmztBTcH7k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:x-enigmail-version:content-type:content-transfer-encoding; b=Zg+SB1kC68q5HDDz6AHbCzq0b2ZXoJjlUoXheCxROoVztgZ+GTTArpHXx2kW+MPLFj NdIh5tNxxnuXzqRlv+bG1bLRwelSOr+laU74KHAHL/EYLUrFafnh2abT+IMhqlwSoYJF qUxzVDzBclYCw1slcBFQdq0vqzOuINCnz5peY= Received: by 10.223.6.27 with SMTP id 27mr3407317fax.31.1268663576628; Mon, 15 Mar 2010 07:32:56 -0700 (PDT) Received: from [114.51.32.107] (EM114-51-32-107.pool.e-mobile.ne.jp [114.51.32.107]) by mx.google.com with ESMTPS id 21sm7204769fkx.40.2010.03.15.07.32.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Mar 2010 07:32:55 -0700 (PDT) Message-ID: <4B9E4521.9030909@yahoo.co.jp> Date: Mon, 15 Mar 2010 23:33:05 +0900 From: IRIE Shinsuke User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: Feature request: Function that returns absolute coordinates X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -4.6 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: irieshinsuke@yahoo.co.jp List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.5 (-----) Recently, I wrote pos-tip.el which allows users to easily show tooltip on arbitrary buffer position (http://www.emacswiki.org/emacs/PosTip). However, external program xwininfo must be called for calculating the absolute coordinates in which tooltip is shown because the location of tooltip must be specified by absolute coordinates, so this program can work only under X window system. Some persons say, "We can calculate absolute coordinates by using `frame-parameter' and `window-pixel-edges'", but it's a mistake. To calculate absolute coordinates under X window system, users must also obtain the pixel height of menu-bar and tool-bar and the pixel width of frame extents, because `window-pixel-edges' returns the location of window relative to a X window corresponding to `window-id', but `frame-parameter' returns the location of a X window corresponding to `outer-window-id' or `parent-id'. That is, these two functions regard the different X windows as `frame'. Unfortunately, there is no way to obtain the tool-bar height etc. without calling external programs such as xwininfo. I also encountered this problem when I wrote scim-bridge.el (http://www.emacswiki.org/emacs/ScimBridge) because SCIM requires the clients to send the absolute coordinates of cursor location. Please implement the functions like `posn-absolute-x-y', `posn-at-absolute-x-y', and `window-absolute-pixel-edges'. IRIE Shinsuke From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 18 22:59:11 2010 Received: (at control) by debbugs.gnu.org; 19 Mar 2010 02:59:12 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NsSQZ-0007Jq-KB for submit@debbugs.gnu.org; Thu, 18 Mar 2010 22:59:11 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NsSQX-0007Jk-Vm for control@debbugs.gnu.org; Thu, 18 Mar 2010 22:59:10 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1NsSQT-0007is-VH; Thu, 18 Mar 2010 22:59:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19362.59513.721447.641996@fencepost.gnu.org> Date: Thu, 18 Mar 2010 22:59:05 -0400 From: Glenn Morris To: control Subject: control X-Attribution: GM X-Mailer: VM (www.wonderworks.com/vm), GNU Emacs (www.gnu.org/software/emacs) X-Hue: cyan X-Ran: pg=Ww3JAIc\=!*)%Z5Fhs9Ym$)~XH{,K X-Debbugs-No-Ack: yes X-Spam-Score: -5.1 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.1 (-----) close 5642 severity 5716 minor tags 5717 moreinfo severity 5721 wishlist reassign 4065 emacs From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 30 13:50:51 2010 Received: (at 5721) by debbugs.gnu.org; 30 Mar 2010 17:50:52 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NwfaV-0003ff-0y for submit@debbugs.gnu.org; Tue, 30 Mar 2010 13:50:51 -0400 Received: from smtprelay-h12.telenor.se ([62.127.194.5]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NwfaT-0003fa-Pw for 5721@debbugs.gnu.org; Tue, 30 Mar 2010 13:50:50 -0400 Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-h12.telenor.se (Postfix) with ESMTP id 0DC6FEA510 for <5721@debbugs.gnu.org>; Tue, 30 Mar 2010 19:50:57 +0200 (CEST) X-SENDER-IP: [85.225.45.110] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsyAG/WsUtV4S1uPGdsb2JhbACDEpgbDAEBAQE1La9bkF6BK4JragQ X-IronPort-AV: E=Sophos;i="4.51,335,1267398000"; d="scan'208";a="57584683" Received: from c-6e2de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.110]) by ipb2.telenor.se with ESMTP; 30 Mar 2010 19:50:44 +0200 Received: from [172.20.199.2] (gaffa [172.20.199.2]) by coolsville.localdomain (Postfix) with ESMTP id E38DF7FA01A; Tue, 30 Mar 2010 19:50:42 +0200 (CEST) Message-ID: <4BB239F2.3040708@swipnet.se> Date: Tue, 30 Mar 2010 19:50:42 +0200 From: =?UTF-8?B?SmFuIERqw6Rydg==?= User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: IRIE Shinsuke Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> In-Reply-To: <4B9E4521.9030909@yahoo.co.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.3 (---) IRIE Shinsuke skrev: > Recently, I wrote pos-tip.el which allows users to easily show tooltip on > arbitrary buffer position (http://www.emacswiki.org/emacs/PosTip). However, > external program xwininfo must be called for calculating the absolute > coordinates in which tooltip is shown because the location of tooltip must > be specified by absolute coordinates, so this program can work only under X > window system. > > Some persons say, "We can calculate absolute coordinates by using > `frame-parameter' and `window-pixel-edges'", but it's a mistake. > > To calculate absolute coordinates under X window system, users must also > obtain the pixel height of menu-bar and tool-bar and the pixel width of > frame extents, because `window-pixel-edges' returns the location of window > relative to a X window corresponding to `window-id', but `frame-parameter' > returns the location of a X window corresponding to `outer-window-id' or > `parent-id'. That is, these two functions regard the different X windows as > `frame'. Unfortunately, there is no way to obtain the tool-bar height etc. > without calling external programs such as xwininfo. > > I also encountered this problem when I wrote scim-bridge.el > (http://www.emacswiki.org/emacs/ScimBridge) because SCIM requires the > clients to send the absolute coordinates of cursor location. > > Please implement the functions like `posn-absolute-x-y', > `posn-at-absolute-x-y', and `window-absolute-pixel-edges'. > I can understand posn-absolute-x-y and window-absolute-pixel-edges, but can you add some details on what posn-at-absolute-x-y should do? I'd rather not introduce another position format that looks like the old, but where pixels are absolute rather than relative. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Mon May 31 06:28:21 2010 Received: (at 5721) by debbugs.gnu.org; 31 May 2010 10:28:21 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OJ2EH-0001GK-Cr for submit@debbugs.gnu.org; Mon, 31 May 2010 06:28:21 -0400 Received: from mail-pz0-f174.google.com ([209.85.222.174]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OJ2ED-0001GE-IS for 5721@debbugs.gnu.org; Mon, 31 May 2010 06:28:18 -0400 Received: by pzk4 with SMTP id 4so585851pzk.7 for <5721@debbugs.gnu.org>; Mon, 31 May 2010 03:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:message-id:in-reply-to:references:reply-to:x-mailer :mime-version:content-type:content-transfer-encoding; bh=TSrRIAeYg3CosjFe9cX1LUbjnpTacQACMF8JZZL2a9g=; b=nXxyZMmrNBaPoKaMP6bbz3c0j305bfwvEIwzwwwJ4ZX4qMjUktmFII8BqXCsdGgIrY JoPElaPjSFQYgcp6kPhHNrJAwyh3XtuEdypveabFahAIsRwwWPNZ0k3cKfWhenYBfs1C taEJGKgbwTzi4fvzucc/192K3je0JjjDgYvHc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :reply-to:x-mailer:mime-version:content-type :content-transfer-encoding; b=LiG0UB0fJCQXIMimXUmSPPeTvJ2KsdUin9b3DQ779Ib7jTlPA9/9IZ3KtwYsRtXusx WXywY37ZfZocYCjNP3vmIY8EnQqEqSii6Xp/bH8Uhnzq3pUCQdnimefBv3sN6XH41Lj/ 1RaHXRGf0YpRvtLPTGdYaYqQ9nQ5yrkUXS3V4= Received: by 10.141.90.14 with SMTP id s14mr3084045rvl.263.1275301694169; Mon, 31 May 2010 03:28:14 -0700 (PDT) Received: from tama (EM114-51-61-250.pool.e-mobile.ne.jp [114.51.61.250]) by mx.google.com with ESMTPS id d14sm4149409rva.6.2010.05.31.03.28.10 (version=SSLv3 cipher=RC4-MD5); Mon, 31 May 2010 03:28:12 -0700 (PDT) Date: Mon, 31 May 2010 19:28:07 +0900 From: IRIE Shinsuke To: Jan =?UTF-8?B?RGrDpHJ2?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates Message-Id: <20100531192807.ee3a9101.irieshinsuke@yahoo.co.jp> In-Reply-To: <4BB239F2.3040708@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4BB239F2.3040708@swipnet.se> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.0; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: irieshinsuke@yahoo.co.jp List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.4 (--) Sorry, I forgot to reply to your question. > I can understand posn-absolute-x-y and window-absolute-pixel-edges, but can > you add some details on what posn-at-absolute-x-y should do? Umm... I suggest the new frame parameters like `inside-left' and `inside-top', which show the top left coordinates of an X window corresponding to `window-id'. See below: A------------------------+ | File Edit Options ... | `left' => horizontal position of A +B----------------------++ `top' => vertical position of A || || `inside-left'=> horizontal position of B || || `inside-top' => vertical position of B || || ||-U:**- *scratch* (lisp|| ||______________________|| +------------------------+ > I'd rather not introduce another position format that looks like the old, but > where pixels are absolute rather than relative. I believe Emacs should provide some ways to obtain absolute coordinates. Recently I created ibus.el, which is an IBus client for Emacs, but it requires the external program to calculate the absolute coordinates of candidate window... IRIE Shinsuke From debbugs-submit-bounces@debbugs.gnu.org Mon May 31 21:16:14 2010 Received: (at 5721) by debbugs.gnu.org; 1 Jun 2010 01:16:14 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OJG5W-0001WU-8b for submit@debbugs.gnu.org; Mon, 31 May 2010 21:16:14 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OJG5U-0001WP-7x for 5721@debbugs.gnu.org; Mon, 31 May 2010 21:16:13 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 2EF30C0557; Tue, 1 Jun 2010 10:16:08 +0900 (JST) Date: Tue, 01 Jun 2010 10:16:08 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: irieshinsuke@yahoo.co.jp Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <20100531192807.ee3a9101.irieshinsuke@yahoo.co.jp> References: <4B9E4521.9030909@yahoo.co.jp> <4BB239F2.3040708@swipnet.se> <20100531192807.ee3a9101.irieshinsuke@yahoo.co.jp> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, Jan =?ISO-8859-1?Q?Dj=E4rv?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Mon, 31 May 2010 19:28:07 +0900, IRIE Shinsuke said: > Sorry, I forgot to reply to your question. >> I can understand posn-absolute-x-y and window-absolute-pixel-edges, but can >> you add some details on what posn-at-absolute-x-y should do? > Umm... I suggest the new frame parameters like `inside-left' and > `inside-top', which show the top left coordinates of an X window > corresponding to `window-id'. See below: > A------------------------+ > | File Edit Options ... | `left' => horizontal position of A > +B----------------------++ `top' => vertical position of A > || || `inside-left'=> horizontal position of B > || || `inside-top' => vertical position of B > || || > ||-U:**- *scratch* (lisp|| > ||______________________|| > +------------------------+ >> I'd rather not introduce another position format that looks like the old, but >> where pixels are absolute rather than relative. > I believe Emacs should provide some ways to obtain absolute coordinates. > Recently I created ibus.el, which is an IBus client for Emacs, but it > requires the external program to calculate the absolute coordinates of > candidate window... 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'. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 08:37:34 2010 Received: (at 5721-done) by debbugs.gnu.org; 1 Jul 2010 12:37:34 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUJ1K-0002Wx-12 for submit@debbugs.gnu.org; Thu, 01 Jul 2010 08:37:34 -0400 Received: from smtprelay-h32.telenor.se ([213.150.131.5]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUJ1H-0002Ws-GW for 5721-done@debbugs.gnu.org; Thu, 01 Jul 2010 08:37:32 -0400 Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-h32.telenor.se (Postfix) with ESMTP id 8038CEB211 for <5721-done@debbugs.gnu.org>; Thu, 1 Jul 2010 14:37:25 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMyAI4oLExV4S0jPGdsb2JhbACDHIRSl3cMAQEBATUtrG2RE4EqgwlyBIZ5 X-IronPort-AV: E=Sophos;i="4.53,520,1272837600"; d="scan'208";a="540208716" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb3.telenor.se with ESMTP; 01 Jul 2010 14:37:24 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id E32A27FA05A; Thu, 1 Jul 2010 14:37:22 +0200 (CEST) Message-ID: <4C2C8C02.1010906@swipnet.se> Date: Thu, 01 Jul 2010 14:37:22 +0200 From: =?UTF-8?B?SmFuIERqw6Rydg==?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: IRIE Shinsuke Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> In-Reply-To: <4B9E4521.9030909@yahoo.co.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721-done Cc: 5721-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) I added functions window-absolute-pixel-edges and window-inside-absolute-pixel-edges. I tested on X and Nextstep (OSX), but they probably do the wrong thing on w32. I don't have w32 available. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 09:08:05 2010 Received: (at 5721-done) by debbugs.gnu.org; 1 Jul 2010 13:08:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUJUr-0002iN-E5 for submit@debbugs.gnu.org; Thu, 01 Jul 2010 09:08:05 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUJUp-0002i1-H8 for 5721-done@debbugs.gnu.org; Thu, 01 Jul 2010 09:08:04 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o61D7urs005561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Jul 2010 13:07:57 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o61CPPdB024762; Thu, 1 Jul 2010 13:07:55 GMT Received: from abhmt014.oracle.com by acsmt354.oracle.com with ESMTP id 373803391277989594; Thu, 01 Jul 2010 06:06:34 -0700 Received: from dradamslap1 (/141.144.168.116) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Jul 2010 06:06:33 -0700 From: "Drew Adams" To: "=?iso-8859-1?Q?'Jan_Dj=E4rv'?=" , "'IRIE Shinsuke'" References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> Subject: RE: bug#5721: Feature request: Function that returnsabsolute coordinates Date: Thu, 1 Jul 2010 06:06:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4C2C8C02.1010906@swipnet.se> Thread-Index: AcsZGi3k5UFNLXS4TMSKw7RjYknqtgAA3w8Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4C2C932C.0075:SCFMA4539814,ss=1,fgs=0 X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 5721-done Cc: 5721-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > I added functions window-absolute-pixel-edges and > window-inside-absolute-pixel-edges. I tested on X and > Nextstep (OSX), but they probably do the wrong thing on w32. > I don't have w32 available. Just out of curiosity, why _close_ a feature request if the new feature "probably does the wrong thing on w32" and has not been tested on w32? Why not keep the bug/request open until the feature is, well, actually implemented? It's great that you made some progress toward providing the feature - thank you, but why close the bug/request before it's finished? Your part might be done, but it seems the feature is not. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 12:53:17 2010 Received: (at 5721) by debbugs.gnu.org; 1 Jul 2010 16:53:17 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUN0n-00048T-0v for submit@debbugs.gnu.org; Thu, 01 Jul 2010 12:53:17 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUN0l-00048O-B1 for 5721@debbugs.gnu.org; Thu, 01 Jul 2010 12:53:15 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o61Gr9oT021355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <5721@debbugs.gnu.org>; Thu, 1 Jul 2010 16:53:10 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o611piRR008495 for <5721@debbugs.gnu.org>; Thu, 1 Jul 2010 16:53:06 GMT Received: from abhmt008.oracle.com by acsmt353.oracle.com with ESMTP id 374687821278003158; Thu, 01 Jul 2010 09:52:38 -0700 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Jul 2010 09:52:38 -0700 From: "Drew Adams" To: <5721@debbugs.gnu.org> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> Subject: RE: bug#5721: Feature request: Function that returnsabsolute coordinates Date: Thu, 1 Jul 2010 09:52:38 -0700 Message-ID: <37FD2C2D7248404ABDFD9FF671F9CB7A@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcsZGi3k5UFNLXS4TMSKw7RjYknqtgAA3w8QAAfyrmA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4C2CC7F3.015D:SCFMA4539814,ss=1,fgs=0 X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 5721 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) Apparently this does not get delivered via Reply, since the address got = changed to 5721-done@debbugs.gnu.org instead of 5721@debbugs.gnu.org. So trying = again, after correcting the address. > From: Drew Adams [mailto:drew.adams@oracle.com]=20 > Sent: Thursday, July 01, 2010 6:07 AM > To: 'Jan Dj=E4rv'; 'IRIE Shinsuke' > Cc: '5721-done@debbugs.gnu.org' > Subject: RE: bug#5721: Feature request: Function that=20 > returnsabsolute coordinates >=20 > > I added functions window-absolute-pixel-edges and=20 > > window-inside-absolute-pixel-edges. I tested on X and=20 > > Nextstep (OSX), but they probably do the wrong thing on w32. > > I don't have w32 available. >=20 > Just out of curiosity, why _close_ a feature request if the=20 > new feature "probably does the wrong thing on w32" and has=20 > not been tested on w32? >=20 > Why not keep the bug/request open until the feature is, well,=20 > actually implemented? >=20 > It's great that you made some progress toward providing the=20 > feature - thank you, but why close the bug/request before=20 > it's finished? Your part might be done, but it seems the=20 > feature is not. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 13:20:56 2010 Received: (at 5721) by debbugs.gnu.org; 1 Jul 2010 17:20:56 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUNRX-0004Ix-OB for submit@debbugs.gnu.org; Thu, 01 Jul 2010 13:20:55 -0400 Received: from smtprelay-b11.telenor.se ([62.127.194.20]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUNRV-0004Is-JN for 5721@debbugs.gnu.org; Thu, 01 Jul 2010 13:20:54 -0400 Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-b11.telenor.se (Postfix) with ESMTP id 69079EB89F for <5721@debbugs.gnu.org>; Thu, 1 Jul 2010 19:20:48 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlA6AClrLExV4S0jPGdsb2JhbACHb5d4DAEBAQE1Lb9ahSUE X-IronPort-AV: E=Sophos;i="4.53,520,1272837600"; d="scan'208";a="96825539" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb2.telenor.se with ESMTP; 01 Jul 2010 19:20:48 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 82F367FA05A; Thu, 1 Jul 2010 19:20:47 +0200 (CEST) Message-ID: <4C2CCE6E.4060105@swipnet.se> Date: Thu, 01 Jul 2010 19:20:46 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#5721: Feature request: Function that returnsabsolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <37FD2C2D7248404ABDFD9FF671F9CB7A@us.oracle.com> In-Reply-To: <37FD2C2D7248404ABDFD9FF671F9CB7A@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) Drew Adams skrev 2010-07-01 18.52: >> Why not keep the bug/request open until the feature is, well, >> actually implemented? >> >> It's great that you made some progress toward providing the >> feature - thank you, but why close the bug/request before >> it's finished? Your part might be done, but it seems the >> feature is not. Just go ahead and implement it, noone is stopping you. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 13:29:40 2010 Received: (at 5721) by debbugs.gnu.org; 1 Jul 2010 17:29:40 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUNa0-0004TI-A4 for submit@debbugs.gnu.org; Thu, 01 Jul 2010 13:29:40 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUNZy-0004TD-Gm for 5721@debbugs.gnu.org; Thu, 01 Jul 2010 13:29:38 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o61HTVOB031171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Jul 2010 17:29:33 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o61GTqnn010653; Thu, 1 Jul 2010 17:29:29 GMT Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 374803071278005268; Thu, 01 Jul 2010 10:27:48 -0700 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Jul 2010 10:27:48 -0700 From: "Drew Adams" To: "=?iso-8859-1?Q?'Jan_Dj=E4rv'?=" References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <37FD2C2D7248404ABDFD9FF671F9CB7A@us.oracle.com> <4C2CCE6E.4060105@swipnet.se> Subject: RE: bug#5721: Feature request: Function that returnsabsolute coordinates Date: Thu, 1 Jul 2010 10:27:48 -0700 Message-ID: <41C052A3E5624691BFB99C8DFC97C007@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4C2CCE6E.4060105@swipnet.se> Thread-Index: AcsZQcF94RRUbXGvTiOxMrWuTID+8AAAMXCw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4C2CD07A.0189:SCFMA4539814,ss=1,fgs=0 X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > >> Why not keep the bug/request open until the feature is, well, > >> actually implemented? > >> > >> It's great that you made some progress toward providing the > >> feature - thank you, but why close the bug/request before > >> it's finished? Your part might be done, but it seems the > >> feature is not. > > Just go ahead and implement it, noone is stopping you. Not the point. I did not ask you to implement it. I asked you to leave the feature request open. That way, someone who might be able to implement it might find it as a to-do. Thx. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 13:50:28 2010 Received: (at 5721) by debbugs.gnu.org; 1 Jul 2010 17:50:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUNu8-0004eG-4H for submit@debbugs.gnu.org; Thu, 01 Jul 2010 13:50:28 -0400 Received: from mail-pv0-f172.google.com ([74.125.83.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUNu7-0004eB-5V for 5721@debbugs.gnu.org; Thu, 01 Jul 2010 13:50:27 -0400 Received: by pvd12 with SMTP id 12so892491pvd.3 for <5721@debbugs.gnu.org>; Thu, 01 Jul 2010 10:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:message-id:from :to:cc:subject:in-reply-to:references:user-agent:mime-version :content-type; bh=ubynhUFm+bUx/JSVpkh1u4XzAZZ0stFZdyyfznyqUX8=; b=cHc9Qs7O0hhC13xCCu3P72KLhxIrD/blEZpb3aOrvh/9xUNU2CPrVY8ceAWnMOduHw QcSD6lXvKM4mZt/+xDi/i8ksYvGan3wZdO4S2UJvRAtFzBtdd95cr/czckg02e9BenOE TtYT2eysgTX5RSZ64zoIxQhvsQ9BdacuOcwpI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:mime-version:content-type; b=v3f0e0jAWYBLSNd8P2ArKc9DwxukX/hJRBoIsiCSHRsOKN6d19qSF19el27cScPkY2 LSqxqbFWz442hNUhuqDEA7EZAdSE+vbkYjyWHMCHsjP03gec8WV8rgz1OZ1KW3/szpaW zc+BuuF9KNEXi8vrVJMjW6fNnliUI2KoBVOZc= Received: by 10.114.164.37 with SMTP id m37mr12486137wae.39.1278006621656; Thu, 01 Jul 2010 10:50:21 -0700 (PDT) Received: from tama.gmail.com (EM114-51-60-100.pool.e-mobile.ne.jp [114.51.60.100]) by mx.google.com with ESMTPS id t25sm72672295wak.22.2010.07.01.10.50.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Jul 2010 10:50:20 -0700 (PDT) Date: Fri, 02 Jul 2010 02:50:08 +0900 Message-ID: <87r5jn148f.wl%irieshinsuke@yahoo.co.jp> From: IRIE Shinsuke To: Jan =?ISO-2022-JP-2?B?RGobJChEKyMbKEJydg==?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C2C8C02.1010906@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.4 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) Thanks, it's great job! I confirmed the functions you implemented work fine on Ubuntu. However, I found a mistake in the docstring of window-absolute-pixel-edges. The docstring says: For the pixel edges of just the text area, use `window-inside-pixel-edges'. `window-inside-pixel-edges' in this sentence should be changed to `window-inside-absolute-pixel-edges'. IRIE Shinsuke From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 14:14:18 2010 Received: (at 5721) by debbugs.gnu.org; 1 Jul 2010 18:14:18 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUOHB-0004oN-QF for submit@debbugs.gnu.org; Thu, 01 Jul 2010 14:14:17 -0400 Received: from smtprelay-h21.telenor.se ([195.54.99.196]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUOH9-0004oI-Ku for 5721@debbugs.gnu.org; Thu, 01 Jul 2010 14:14:16 -0400 Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-h21.telenor.se (Postfix) with ESMTP id 766D1CD8C for <5721@debbugs.gnu.org>; Thu, 1 Jul 2010 20:14:08 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlA6AD54LExV4S0jPGdsb2JhbACHb5d5DAEBAQE1Lb9RhSUEhns X-IronPort-AV: E=Sophos;i="4.53,521,1272837600"; d="scan'208";a="540348649" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb3.telenor.se with ESMTP; 01 Jul 2010 20:14:08 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 1B3D07FA05A; Thu, 1 Jul 2010 20:14:07 +0200 (CEST) Message-ID: <4C2CDAEE.1000008@swipnet.se> Date: Thu, 01 Jul 2010 20:14:06 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: IRIE Shinsuke Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <87r5jn148f.wl%irieshinsuke@yahoo.co.jp> In-Reply-To: <87r5jn148f.wl%irieshinsuke@yahoo.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.3 (---) IRIE Shinsuke skrev 2010-07-01 19.50: > Thanks, it's great job! I confirmed the functions you implemented work fine > on Ubuntu. > > However, I found a mistake in the docstring of window-absolute-pixel-edges. > The docstring says: > > For the pixel edges of just the text area, use `window-inside-pixel-edges'. > > `window-inside-pixel-edges' in this sentence should be changed to > `window-inside-absolute-pixel-edges'. > Thanks, fixed now. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 14:26:21 2010 Received: (at 5721) by debbugs.gnu.org; 1 Jul 2010 18:26:21 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUOSr-0004tW-75 for submit@debbugs.gnu.org; Thu, 01 Jul 2010 14:26:21 -0400 Received: from smtprelay-b12.telenor.se ([62.127.194.21]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUOSp-0004tQ-E6 for 5721@debbugs.gnu.org; Thu, 01 Jul 2010 14:26:20 -0400 Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-b12.telenor.se (Postfix) with ESMTP id 63943D1AF for <5721@debbugs.gnu.org>; Thu, 1 Jul 2010 20:26:14 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlA6AFp6LExV4S0jPGdsb2JhbACHb5d5DAEBAQE1Lb9GhSUE X-IronPort-AV: E=Sophos;i="4.53,521,1272837600"; d="scan'208";a="96852336" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb2.telenor.se with ESMTP; 01 Jul 2010 20:26:11 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 30FEA7FA05A; Thu, 1 Jul 2010 20:26:11 +0200 (CEST) Message-ID: <4C2CDDC2.9090104@swipnet.se> Date: Thu, 01 Jul 2010 20:26:10 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#5721: Feature request: Function that returnsabsolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <37FD2C2D7248404ABDFD9FF671F9CB7A@us.oracle.com> <4C2CCE6E.4060105@swipnet.se> <41C052A3E5624691BFB99C8DFC97C007@us.oracle.com> In-Reply-To: <41C052A3E5624691BFB99C8DFC97C007@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.3 (---) Drew Adams skrev 2010-07-01 19.27: > > Not the point. I did not ask you to implement it. I asked you to leave the > feature request open. That way, someone who might be able to implement it might > find it as a to-do. Thx. I don't think those working with w32 browse the bug tracker to find tasks to do. But besides that, this is free software. Unless a bug explicitly mentions w32, I do think it is done when it is implemented for free systems (in this case, nextstep and X). I will try to not break compilation for non-free systems, but that is as far as I go. The state of Emacs should not depend on how well it performs on non-free systems. If people want to use their time to get Emacs going on non-free systems, that is up to them. But the main drive for Emacs are free systems, and those are the ones that must count w.r.t. bugs and feature requests. If you can't implement it, file a new w32-specific bug. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 14:54:12 2010 Received: (at 5721) by debbugs.gnu.org; 1 Jul 2010 18:54:12 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUOtn-00055v-R5 for submit@debbugs.gnu.org; Thu, 01 Jul 2010 14:54:12 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUOtm-00055q-Ay for 5721@debbugs.gnu.org; Thu, 01 Jul 2010 14:54:10 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o61Is45X016751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Jul 2010 18:54:05 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o61E8moB025818; Thu, 1 Jul 2010 18:54:01 GMT Received: from abhmt018.oracle.com by acsmt354.oracle.com with ESMTP id 375088781278010366; Thu, 01 Jul 2010 11:52:46 -0700 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Jul 2010 11:52:46 -0700 From: "Drew Adams" To: "=?iso-8859-1?Q?'Jan_Dj=E4rv'?=" References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <37FD2C2D7248404ABDFD9FF671F9CB7A@us.oracle.com> <4C2CCE6E.4060105@swipnet.se> <41C052A3E5624691BFB99C8DFC97C007@us.oracle.com> <4C2CDDC2.9090104@swipnet.se> Subject: RE: bug#5721: Feature request: Function that returnsabsolute coordinates Date: Thu, 1 Jul 2010 11:52:46 -0700 Message-ID: <2989ADE6BCAF46908BF3BA0344D9CC70@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4C2CDDC2.9090104@swipnet.se> Thread-Index: AcsZSuWRiFF9Pf2IQ76AF6S7nJoXYgAAebjA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4C2CE44A.019B:SCFMA4539814,ss=1,fgs=0 X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > > Not the point. I did not ask you to implement it. I asked > > you to leave the feature request open. That way, someone > > who might be able to implement it might find it as a to-do. Thx. > > I don't think those working with w32 browse the bug tracker > to find tasks to do. How do you know? > But besides that, this is free software. Unless a bug > explicitly mentions w32, I do think it is done when it is > implemented for free systems (in this case, nextstep and X). > I will try to not break compilation for non-free > systems, but that is as far as I go. It's not about _you_. As I said before, your part might well be done - which you are repeating "as far as I go". But that does not mean that the requested feature is done, or that Emacs is done as far as the feature is concerned. You are not Emacs. Your Emacs development is not the same as Emacs development. > The state of Emacs should not depend on how well it performs > on non-free systems. The state of Emacs for a given platform depends on how well it performs on that platform. Emacs on w32 is Emacs. GNU Emacs on w32 is GNU Emacs. > If people want to use their time to get Emacs going on non-free > systems, that is up to them. Yes, it is. The bug/feature request is for "people" and for "Emacs", not just for you. > But the main drive for Emacs are free systems, I have no argument with that. > and those are the ones that must count w.r.t. bugs > and feature requests. No. There is nothing wrong with filing Emacs bugs and feature requests that affect w32. And there is nothing wrong with fixing them. They most certainly do count for Emacs. Features and bugs that are w32-specific are not "the main drive" for Emacs, but they count for Emacs. And so does the implementation on w32 of features (such as this one) which are not w32-specific. > If you can't implement it, file a new w32-specific bug. Done. Ridiculous, but done. If the feature originally requested were specific to a particular platform, then I would agree with you. IIUC, it is not. If that is correct, then there is no reason to file platform-specific versions of the feature. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 16:08:50 2010 Received: (at 5721) by debbugs.gnu.org; 1 Jul 2010 20:08:50 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUQ42-0005W0-2t for submit@debbugs.gnu.org; Thu, 01 Jul 2010 16:08:50 -0400 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUQ3z-0005Vv-UX for 5721@debbugs.gnu.org; Thu, 01 Jul 2010 16:08:48 -0400 Received: by bwz7 with SMTP id 7so1222854bwz.3 for <5721@debbugs.gnu.org>; Thu, 01 Jul 2010 13:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=n9wDdp23p3rtOQ6eRPLHdb1GLKi3SvwtOZ7/QWu0SM8=; b=S0c/XmV3v5AdD/Zwgx8EpnU+4f1+XFeFOa/xp7W8rSI4Cp0lA625ZKhBt47t8YlaFR NBCP4I3hDmtwsbsnRFA0qNrR+ygQu8vssyfNlFcQY7QlAe6F0c6poZB2JlFtZNWhluAk uHXmkZ/THDXnWlRmLIbDz1SiuLfSPBrGlMRG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=bolWXSOVNy51Yno8nb9/UDS8Rps9Xb9wIHepbkknj6PV6X4b5X6ckjRem4b2ypta9K Dd7GeP3GLlqRw6Hp7rsYrBZQK1wyKPctSapIz2kSt4HTiUxWBeXIHyIaH9nli3Et2MUm edqh80ixSKp2y+neqIo7CHRuy/j8O3ouXcyX8= Received: by 10.204.55.65 with SMTP id t1mr679687bkg.128.1278014922211; Thu, 01 Jul 2010 13:08:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.66.77 with HTTP; Thu, 1 Jul 2010 13:08:21 -0700 (PDT) In-Reply-To: <4C2CDDC2.9090104@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <37FD2C2D7248404ABDFD9FF671F9CB7A@us.oracle.com> <4C2CCE6E.4060105@swipnet.se> <41C052A3E5624691BFB99C8DFC97C007@us.oracle.com> <4C2CDDC2.9090104@swipnet.se> From: Juanma Barranquero Date: Thu, 1 Jul 2010 22:08:21 +0200 Message-ID: Subject: Re: bug#5721: Feature request: Function that returnsabsolute coordinates To: =?UTF-8?Q?Jan_Dj=C3=A4rv?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) On Thu, Jul 1, 2010 at 20:26, Jan Dj=C3=A4rv wrote: > I don't think those working with w32 browse the bug tracker to find tasks= to > do. Well, you are mistaken. > But besides that, this is free software. =C2=A0Unless a bug explicitly me= ntions > w32, I do think it is done when it is implemented for free systems (in th= is > case, nextstep and X). Free software running on a non-free operating system is still free software. So fixing a bug or adding a feature is *not* done while it is not implemented on all supported platforms; that's unrelated to the issue of whether non-free OSes are a priority, etc. > I will try to not break compilation for non-free > systems, but that is as far as I go. Oh, I try not to break compilation for free systems, but that's as far as I= go. > If you can't implement it, file a new w32-specific bug. That is ridiculous. Juanma From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 18:05:58 2010 Received: (at 5721) by debbugs.gnu.org; 1 Jul 2010 22:05:58 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OURtN-0006F3-Vv for submit@debbugs.gnu.org; Thu, 01 Jul 2010 18:05:58 -0400 Received: from mail-ew0-f44.google.com ([209.85.215.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OURtM-0006Ey-4a for 5721@debbugs.gnu.org; Thu, 01 Jul 2010 18:05:56 -0400 Received: by ewy22 with SMTP id 22so881068ewy.3 for <5721@debbugs.gnu.org>; Thu, 01 Jul 2010 15:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=hg9jh2fS+jA1sx5Kxl/G0OL/RYEYduxcdWTQcBwIZBc=; b=SdIsyAUV2dRGt1wgaUSUu+4QNMDdorsbG4LMsemxGIlYHh5LTp7cyUxfB4Awowh6lL NtzUXsX2Fi8e+MVv4/Efewh5v9GNPCuHmlgjezKz8fjokKDkgSjSNuGK94qB14Bv1f4Z m933gVISvR1rrqhJI3nl/e0YqMzEBkb8ceiR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=iXqRA6hSWi/aVQ6LuLD3upfQilA++xuNanLgJppWQmSmK+kXIjKey7rR3uIgOvWWzm 6uSyam0E0C+Go0ivjZZGqw7b1muhBAR0GGLoVAr5Koo1yfPILjQ9GYY9CWVKYHuUsOtr FUXyo9ML8RukaXMYU1p8DItud4raDj/AQEwEU= Received: by 10.213.112.144 with SMTP id w16mr120948ebp.40.1278021951533; Thu, 01 Jul 2010 15:05:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.15.132 with HTTP; Thu, 1 Jul 2010 15:05:27 -0700 (PDT) In-Reply-To: <4C2CDDC2.9090104@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <37FD2C2D7248404ABDFD9FF671F9CB7A@us.oracle.com> <4C2CCE6E.4060105@swipnet.se> <41C052A3E5624691BFB99C8DFC97C007@us.oracle.com> <4C2CDDC2.9090104@swipnet.se> From: Lennart Borgman Date: Fri, 2 Jul 2010 00:05:27 +0200 Message-ID: Subject: Re: bug#5721: Feature request: Function that returnsabsolute coordinates To: =?UTF-8?Q?Jan_Dj=C3=A4rv?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) On Thu, Jul 1, 2010 at 8:26 PM, Jan Dj=C3=A4rv wrote: > > But besides that, this is free software. =C2=A0Unless a bug explicitly me= ntions > w32, I do think it is done when it is implemented for free systems (in th= is > case, nextstep and X). Oh, please, I think that would make a mess of Emacs. Leave bugs open until they are implemented on all relevant platforms! Without that a lot of time will be wasted when other people again tries to find out why things do not work. > I will try to not break compilation for non-free > systems, but that is as far as I go. Thanks. No one expects you to implement this on w32. > The state of Emacs should not depend > on how well it performs on non-free systems. There are already a lot of bug reports. I think duplicating them is not wis= e. > If you can't implement it, file a new w32-specific bug. No. Please don't! From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 20:33:35 2010 Received: (at 5721) by debbugs.gnu.org; 2 Jul 2010 00:33:35 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUUCF-0007or-5m for submit@debbugs.gnu.org; Thu, 01 Jul 2010 20:33:35 -0400 Received: from mail-gx0-f172.google.com ([209.85.161.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUUCD-0007om-KN for 5721@debbugs.gnu.org; Thu, 01 Jul 2010 20:33:34 -0400 Received: by gxk28 with SMTP id 28so278421gxk.3 for <5721@debbugs.gnu.org>; Thu, 01 Jul 2010 17:33:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.88.7 with SMTP id l7mr290235agb.179.1278030809527; Thu, 01 Jul 2010 17:33:29 -0700 (PDT) Received: by 10.151.46.4 with HTTP; Thu, 1 Jul 2010 17:33:29 -0700 (PDT) Date: Thu, 1 Jul 2010 20:33:29 -0400 X-Google-Sender-Auth: _4DAOQb9QwZYGRdGVCNxYjyJyiw Message-ID: Subject: bug#5721: Feature request: Function that returns absolute coordinates From: MON KEY To: jan.h.d@swipnet.se Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.7 (-) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) >> I don't think those working with w32 browse the bug tracker to find tasks >> to do. I have Emacs installed on various GNU/Linux and w32 machines. I use the bug tracker as a means to track how bugs might affect Emacs installations on different platforms. >> But the main drive for Emacs are free systems, In recent times maybe. Emacs is over 30yrs old and predates both the GNU project and contemporary notions of `free'. The Emacs we have today wouldn't be here were it not for users/developers who built and maintained earlier Emacsen for non-free systems. FWIW prolonged usage/exposure to Emacs on w32 helped me to become and advocate and supporter of GNU distros and GNU ideals. -- /s_P\ From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 22:10:27 2010 Received: (at 5721) by debbugs.gnu.org; 2 Jul 2010 02:10:27 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUVhy-0008Ou-PS for submit@debbugs.gnu.org; Thu, 01 Jul 2010 22:10:26 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUVhv-0008Ol-Go for 5721@debbugs.gnu.org; Thu, 01 Jul 2010 22:10:25 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 2FCE0C0560; Fri, 2 Jul 2010 11:10:17 +0900 (JST) Date: Fri, 02 Jul 2010 11:10:16 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: 5721@debbugs.gnu.org, Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C2C8C02.1010906@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 5721 Cc: IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) >>>>> On Thu, 01 Jul 2010 14:37:22 +0200, Jan Dj=E4rv = said: > I added functions window-absolute-pixel-edges and > window-inside-absolute-pixel-edges. I tested on X and Nextstep > (OSX), but they probably do the wrong thing on w32. I don't have > w32 available. What do you think about the following point? >>>>> On Tue, 01 Jun 2010 10:16:08 +0900, YAMAMOTO Mitsuharu 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/Con= ceptual/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. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 02 03:06:58 2010 Received: (at 5721) by debbugs.gnu.org; 2 Jul 2010 07:06:58 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUaKv-0001hi-Nx for submit@debbugs.gnu.org; Fri, 02 Jul 2010 03:06:58 -0400 Received: from smtprelay-b11.telenor.se ([62.127.194.20]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUaKt-0001hd-2D for 5721@debbugs.gnu.org; Fri, 02 Jul 2010 03:06:56 -0400 Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-b11.telenor.se (Postfix) with ESMTP id 66AF1DFAD for <5721@debbugs.gnu.org>; Fri, 2 Jul 2010 09:06:51 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmU8AFUsLUxV4S0jPGdsb2JhbACfaQwBAQEBNS29TYUlBIQXjTg X-IronPort-AV: E=Sophos;i="4.53,525,1272837600"; d="scan'208";a="97197680" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb2.telenor.se with ESMTP; 02 Jul 2010 09:06:50 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 29A727FA05A; Fri, 2 Jul 2010 09:06:50 +0200 (CEST) Message-ID: <4C2D9009.60405@swipnet.se> Date: Fri, 02 Jul 2010 09:06:49 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) 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 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 02 05:15:53 2010 Received: (at 5721) by debbugs.gnu.org; 2 Jul 2010 09:15:53 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUcLg-0002UO-Pm for submit@debbugs.gnu.org; Fri, 02 Jul 2010 05:15:53 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUcLe-0002UH-2z for 5721@debbugs.gnu.org; Fri, 02 Jul 2010 05:15:51 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 78416C0563; Fri, 2 Jul 2010 18:15:44 +0900 (JST) Date: Fri, 02 Jul 2010 18:15:44 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C2D9009.60405@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke , YAMAMOTO Mitsuharu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Fri, 02 Jul 2010 09:06:49 +0200, Jan Dj=E4rv = 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/Concept= ual/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 From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 14 11:22:23 2010 Received: (at 5721) by debbugs.gnu.org; 14 Jul 2010 15:22:24 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZ3mx-0005yQ-Li for submit@debbugs.gnu.org; Wed, 14 Jul 2010 11:22:23 -0400 Received: from smtprelay-b11.telenor.se ([62.127.194.20]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZ3mv-0005yL-4W for 5721@debbugs.gnu.org; Wed, 14 Jul 2010 11:22:21 -0400 Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-b11.telenor.se (Postfix) with ESMTP id D0FEBE94DD for <5721@debbugs.gnu.org>; Wed, 14 Jul 2010 17:22:28 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQ4AAZzPUxV4S0jPGdsb2JhbACHcJd6DAEBAQE1LcA1hSQEkg0 X-IronPort-AV: E=Sophos;i="4.55,202,1278280800"; d="scan'208";a="105323147" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb1.telenor.se with ESMTP; 14 Jul 2010 17:22:28 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 3E24C7FA05A; Wed, 14 Jul 2010 17:22:28 +0200 (CEST) Message-ID: <4C3DD633.7040004@swipnet.se> Date: Wed, 14 Jul 2010 17:22:27 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) YAMAMOTO Mitsuharu skrev 2010-07-02 11.15: >>>>>> On Fri, 02 Jul 2010 09:06:49 +0200, Jan Dj=E4rv 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. > I would imagine that for frame positioning, absolute scaled would be the=20 default, as top and left frame parameters should also be absolute scaled. To pass absolute unscaled to an external program or to position on absolu= te=20 unscaled a special functions would be needed. But I don't think a functi= on=20 that gives window edges is the place to do that. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 14 20:17:53 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 00:17:54 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZC9B-00045A-I9 for submit@debbugs.gnu.org; Wed, 14 Jul 2010 20:17:53 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZC98-000455-I1 for 5721@debbugs.gnu.org; Wed, 14 Jul 2010 20:17:52 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 51F4AC0557; Thu, 15 Jul 2010 09:17:57 +0900 (JST) Date: Thu, 15 Jul 2010 09:17:57 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C3DD633.7040004@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Wed, 14 Jul 2010 17:22:27 +0200, Jan Dj=E4rv = said: >> 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. > I would imagine that for frame positioning, absolute scaled would be the = > default, as top and left frame parameters should also be absolute > scaled. That would bring us coarser precision with respect to the frame position. If the scale factor is 2, then we cannot place a frame to a position whose coordinate is an odd number (in absolute unscaled). On Mac OS X, the window (in window system terminology) position should be specified in the unscaled coordinate system even with non-indentity scale factor. > To pass absolute unscaled to an external program or to position on > absolute unscaled a special functions would be needed. But I don't > think a function that gives window edges is the place to do that. I doubt the OP still wants window edges in absolute coordinates systems, once he knows simple offsetting is not sufficient in general (i.e., with scale factor). I'm thinking about an interface that is parallel to posn-at-x-y and returns absolute unscaled coordinates instead of position information. (posn-at-x-y x y &optional frame-or-window whole) Return position information for pixel coordinates x and y. By default, x and y are relative to text area of the selected window. Optional third arg frame-or-window non-nil specifies frame or window. If optional fourth arg whole is non-nil, x is relative to the left edge of the window. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 02:07:22 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 06:07:22 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZHbN-0006I6-Np for submit@debbugs.gnu.org; Thu, 15 Jul 2010 02:07:22 -0400 Received: from smtprelay-h22.telenor.se ([195.54.99.197]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZHbL-0006Hz-KV for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 02:07:20 -0400 Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-h22.telenor.se (Postfix) with ESMTP id AD190E9EC1 for <5721@debbugs.gnu.org>; Thu, 15 Jul 2010 08:07:28 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEyAGNCPkxV4S0jPGdsb2JhbACHcZgCDAEBAQE1Lb81hSQEkg0 X-IronPort-AV: E=Sophos;i="4.55,206,1278280800"; d="scan'208";a="547959948" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb3.telenor.se with ESMTP; 15 Jul 2010 08:07:27 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 4408A7FA05A; Thu, 15 Jul 2010 08:07:27 +0200 (CEST) Message-ID: <4C3EA59E.40300@swipnet.se> Date: Thu, 15 Jul 2010 08:07:26 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) YAMAMOTO Mitsuharu skrev 2010-07-15 02.17: >>>>>> On Wed, 14 Jul 2010 17:22:27 +0200, Jan Dj=E4rv said: > >>> 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. > >> I would imagine that for frame positioning, absolute scaled would be t= he >> default, as top and left frame parameters should also be absolute >> scaled. > > That would bring us coarser precision with respect to the frame > position. If the scale factor is 2, then we cannot place a frame to a > position whose coordinate is an odd number (in absolute unscaled). As I said below, special functions to do that based on unscaled coordinat= es=20 would be needed. But for the default scaled should be used. Placing too= ltips=20 for example is much more common than placing frames. Doing so based on s= caled=20 coordinates is no problem. The alternative, to use unscaled, would make = Emacs=20 internals everywhere have to handle two coordinate systems all the time. = To=20 knowingly introduce such an overhead on everything is madness. > > I doubt the OP still wants window edges in absolute coordinates > systems, once he knows simple offsetting is not sufficient in general > (i.e., with scale factor). > If all coordinates and sizes he uses are scaled, why isn't it sufficient? Jan D. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 02:49:04 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 06:49:04 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZIFj-0006aT-9o for submit@debbugs.gnu.org; Thu, 15 Jul 2010 02:49:03 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZIFf-0006aH-LO for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 02:49:01 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 698CEC0557; Thu, 15 Jul 2010 15:49:06 +0900 (JST) Date: Thu, 15 Jul 2010 15:49:06 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C3EA59E.40300@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Thu, 15 Jul 2010 08:07:26 +0200, Jan Dj=E4rv = said: >>> I would imagine that for frame positioning, absolute scaled would >>> be the default, as top and left frame parameters should also be >>> absolute scaled. >>=20 >> That would bring us coarser precision with respect to the frame >> position. If the scale factor is 2, then we cannot place a frame >> to a position whose coordinate is an odd number (in absolute >> unscaled). > As I said below, special functions to do that based on unscaled > coordinates would be needed. But for the default scaled should be > used. 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? > 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 +=3D f->left_pos + FRAME_OUTER_TO_INNER_DIFF_X (f)'. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 03:50:02 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 07:50:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZJCi-0007dx-Qo for submit@debbugs.gnu.org; Thu, 15 Jul 2010 03:50:02 -0400 Received: from smtprelay-h31.telenor.se ([213.150.131.4]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZJCh-0007dr-9Y for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 03:50:00 -0400 Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-h31.telenor.se (Postfix) with ESMTP id CCC8DE9DB5 for <5721@debbugs.gnu.org>; Thu, 15 Jul 2010 09:50:08 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsM1AANbPkxV4S0jPGdsb2JhbACHcZgCDAEBAQE1Lb5VgnAIgiwEhCCNbQ X-IronPort-AV: E=Sophos;i="4.55,206,1278280800"; d="scan'208";a="547995910" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb3.telenor.se with ESMTP; 15 Jul 2010 09:50:07 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id D896D7FA05A; Thu, 15 Jul 2010 09:50:06 +0200 (CEST) Message-ID: <4C3EBDAD.1040800@swipnet.se> Date: Thu, 15 Jul 2010 09:50:05 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 03:59:03 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 07:59:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZJLS-0007hb-A7 for submit@debbugs.gnu.org; Thu, 15 Jul 2010 03:59:02 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZJLP-0007hT-Iw for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 03:59:01 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 0D93EC0557; Thu, 15 Jul 2010 16:59:07 +0900 (JST) Date: Thu, 15 Jul 2010 16:59:06 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C3EBDAD.1040800@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Thu, 15 Jul 2010 09:50:05 +0200, Jan Dj=E4rv = said: >> 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. >>=20 >>> Placing tooltips for example is much more common than placing >>> frames. Doing so based on scaled coordinates is no problem. >>=20 >> 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. >>=20 >> 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 +=3D 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. In what sense can they be simplified if we used absolute scaled coordinate in Lisp as you say? Window system APIs requires us to specify absolute unscaled coordinates when creating windows or popup menus, so some conversions are necessary anyway. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 04:06:18 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 08:06:18 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZJSS-0007l5-JQ for submit@debbugs.gnu.org; Thu, 15 Jul 2010 04:06:17 -0400 Received: from smtprelay-h32.telenor.se ([213.150.131.5]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZJSR-0007kz-2o for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 04:06:15 -0400 Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-h32.telenor.se (Postfix) with ESMTP id B43C3E833B for <5721@debbugs.gnu.org>; Thu, 15 Jul 2010 10:06:24 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsM1AIJePkxV4S0jPGdsb2JhbACHcZgCDAEBAQE1Lb5EhSQEkg0 X-IronPort-AV: E=Sophos;i="4.55,206,1278280800"; d="scan'208";a="548001941" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb3.telenor.se with ESMTP; 15 Jul 2010 10:06:24 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id EB6AA7FA05A; Thu, 15 Jul 2010 10:06:23 +0200 (CEST) Message-ID: <4C3EC17E.6060101@swipnet.se> Date: Thu, 15 Jul 2010 10:06:22 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) YAMAMOTO Mitsuharu skrev 2010-07-15 09.59: > >> I think your "only" is quite big. Lots of code, C and Lisp, does >> that kind of calculation. > > In what sense can they be simplified if we used absolute scaled > coordinate in Lisp as you say? Then they wouldn't need to be changed at all. > Window system APIs requires us to > specify absolute unscaled coordinates when creating windows or popup > menus, so some conversions are necessary anyway. > That is the job of the platform specific code. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 04:18:15 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 08:18:16 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZJe3-0007q0-Or for submit@debbugs.gnu.org; Thu, 15 Jul 2010 04:18:15 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZJe1-0007pu-BO for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 04:18:14 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 19CD7C0557; Thu, 15 Jul 2010 17:18:20 +0900 (JST) Date: Thu, 15 Jul 2010 17:18:20 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C3EC17E.6060101@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Thu, 15 Jul 2010 10:06:22 +0200, Jan Dj=E4rv = said: >>> I think your "only" is quite big. Lots of code, C and Lisp, does >>> that kind of calculation. >>=20 >> In what sense can they be simplified if we used absolute scaled >> coordinate in Lisp as you say? > Then they wouldn't need to be changed at all. Even with absolute unscaled, they DIDN'T need any changes in the platform independent part. >> Window system APIs requires us to specify absolute unscaled >> coordinates when creating windows or popup menus, so some >> conversions are necessary anyway. > That is the job of the platform specific code. So you agree that changes are necessary in the platform specific part regardless of scaled or unscaled when we support scaling factor? Again, if we used absolute scaled coordinates to specify `left' and `top' frame parameters, we could only place the frame to the position whose coordinates are multiples of the scale factor. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 04:35:42 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 08:35:43 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZJuv-0007x0-Nz for submit@debbugs.gnu.org; Thu, 15 Jul 2010 04:35:42 -0400 Received: from smtprelay-b12.telenor.se ([62.127.194.21]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZJut-0007wv-CB for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 04:35:40 -0400 Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-b12.telenor.se (Postfix) with ESMTP id 171C0EA04B for <5721@debbugs.gnu.org>; Thu, 15 Jul 2010 10:35:48 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsM1AItlPkxV4S0jPGdsb2JhbACHcZgCDAEBAQE1Lb47hSQEkg0 X-IronPort-AV: E=Sophos;i="4.55,206,1278280800"; d="scan'208";a="105668584" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb1.telenor.se with ESMTP; 15 Jul 2010 10:35:48 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 139A57FA05A; Thu, 15 Jul 2010 10:35:48 +0200 (CEST) Message-ID: <4C3EC863.3030803@swipnet.se> Date: Thu, 15 Jul 2010 10:35:47 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.3 (---) YAMAMOTO Mitsuharu skrev 2010-07-15 10.18: >>>>>> On Thu, 15 Jul 2010 10:06:22 +0200, Jan Dj=E4rv said: > >>>> I think your "only" is quite big. Lots of code, C and Lisp, does >>>> that kind of calculation. >>> >>> In what sense can they be simplified if we used absolute scaled >>> coordinate in Lisp as you say? > >> Then they wouldn't need to be changed at all. > > Even with absolute unscaled, they DIDN'T need any changes in the > platform independent part. That would require unscaled everywhere, even in pos-x-y, window sizes, fo= nt=20 sizes and so on. I didin't think that was your suggestion. > >>> Window system APIs requires us to specify absolute unscaled >>> coordinates when creating windows or popup menus, so some >>> conversions are necessary anyway. > >> That is the job of the platform specific code. > > So you agree that changes are necessary in the platform specific part > regardless of scaled or unscaled when we support scaling factor? > I've said that from the start. > Again, if we used absolute scaled coordinates to specify `left' and > `top' frame parameters, we could only place the frame to the position > whose coordinates are multiples of the scale factor. > As I said earlier, special functions to deal with that for those that car= e. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 04:44:24 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 08:44:25 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZK3L-00081c-7R for submit@debbugs.gnu.org; Thu, 15 Jul 2010 04:44:23 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZK3I-00081V-JD for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 04:44:22 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 06BE8C0557; Thu, 15 Jul 2010 17:44:28 +0900 (JST) Date: Thu, 15 Jul 2010 17:44:28 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C3EC863.3030803@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Thu, 15 Jul 2010 10:35:47 +0200, Jan Dj=E4rv = said: >> Even with absolute unscaled, they DIDN'T need any changes in the >> platform independent part. > That would require unscaled everywhere, even in pos-x-y, window > sizes, font sizes and so on. I didin't think that was your > suggestion. No, they are all frame-relative, so scaled by the scaling factor. The only places currently I can think of in the "absolute" category are the frame parameters `left' and `top', and some screen parameters such as `display-pixel-height', etc. Most of the values in Lisp are designed as frame-relative. >> Again, if we used absolute scaled coordinates to specify `left' and >> `top' frame parameters, we could only place the frame to the >> position whose coordinates are multiples of the scale factor. > As I said earlier, special functions to deal with that for those that car= e. I don't understand. What happens if a user moved the frame to (101, 101) using the mouse under the scale factor 2, and he checked (frame-parameter nil 'left)? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 04:59:59 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 08:59:59 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZKIQ-00088P-UO for submit@debbugs.gnu.org; Thu, 15 Jul 2010 04:59:59 -0400 Received: from smtprelay-h21.telenor.se ([195.54.99.196]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZKIO-00088K-DB for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 04:59:57 -0400 Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-h21.telenor.se (Postfix) with ESMTP id AF239E9AB4 for <5721@debbugs.gnu.org>; Thu, 15 Jul 2010 11:00:05 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsM1AGdrPkxV4S0jPGdsb2JhbACHcZd9DAEBAQE1Lb5IhSQEkg0 X-IronPort-AV: E=Sophos;i="4.55,207,1278280800"; d="scan'208";a="105677333" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb1.telenor.se with ESMTP; 15 Jul 2010 10:59:52 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 983197FA05A; Thu, 15 Jul 2010 10:59:52 +0200 (CEST) Message-ID: <4C3ECE08.2040604@swipnet.se> Date: Thu, 15 Jul 2010 10:59:52 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.3 (---) YAMAMOTO Mitsuharu skrev 2010-07-15 10.44: >>>>>> On Thu, 15 Jul 2010 10:35:47 +0200, Jan Dj=E4rv said: >> That would require unscaled everywhere, even in pos-x-y, window >> sizes, font sizes and so on. I didin't think that was your >> suggestion. > > No, they are all frame-relative, so scaled by the scaling factor. > > The only places currently I can think of in the "absolute" category > are the frame parameters `left' and `top', and some screen parameters > such as `display-pixel-height', etc. Most of the values in Lisp are > designed as frame-relative. But many operations add and subtract from frame top, left and display=20 width/height. How many? I don't know, I just suspect that there are man= y=20 based on what I've seen when editing existing lisp files in Emacs. Not t= o=20 mention C files. > >>> Again, if we used absolute scaled coordinates to specify `left' and >>> `top' frame parameters, we could only place the frame to the >>> position whose coordinates are multiples of the scale factor. > >> As I said earlier, special functions to deal with that for those that = care. > > I don't understand. What happens if a user moved the frame to (101, > 101) using the mouse under the scale factor 2, and he checked > (frame-parameter nil 'left)? Is 101 scaled or unscaled? If scaled, left would be 101. If not scaled, left would be 50. Loss of precision? Sure, but does it ma= tter=20 in most cases? Another idea would be if Emacs had its own internal coordinate system, sa= y 0.0=20 to 1.0 or some integer based one, that already is display independent. It would fit nicely with the GnomeCanvas idea (see other thread). A bunch of work though... Jan D. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 05:27:25 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 09:27:25 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZKix-0008Jh-7j for submit@debbugs.gnu.org; Thu, 15 Jul 2010 05:27:23 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZKit-0008Jc-Tm for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 05:27:21 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id ED651C0557; Thu, 15 Jul 2010 18:27:26 +0900 (JST) Date: Thu, 15 Jul 2010 18:27:26 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C3ECE08.2040604@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Thu, 15 Jul 2010 10:59:52 +0200, Jan Dj=E4rv = said: >>> That would require unscaled everywhere, even in pos-x-y, window >>> sizes, font sizes and so on. I didin't think that was your >>> suggestion. >>=20 >> No, they are all frame-relative, so scaled by the scaling factor. >>=20 >> The only places currently I can think of in the "absolute" category >> are the frame parameters `left' and `top', and some screen >> parameters such as `display-pixel-height', etc. Most of the values >> in Lisp are designed as frame-relative. > But many operations add and subtract from frame top, left and > display width/height. How many? I don't know, I just suspect that > there are many based on what I've seen when editing existing lisp > files in Emacs. Not to mention C files. Such operations are inherently relative-absolute conversions, and such tasks should be done by a special conversion function we are introducing. For most such use cases, we must take window decorations (including the title bar) by the window manager into account anyway, and the relative-scaled <-> absolute-unscaled conversion function will make it more accurate, concise, and makes the intention clear. >>>> Again, if we used absolute scaled coordinates to specify `left' >>>> and `top' frame parameters, we could only place the frame to the >>>> position whose coordinates are multiples of the scale factor. >>=20 >>> As I said earlier, special functions to deal with that for those >>> that care. >>=20 >> I don't understand. What happens if a user moved the frame to >> (101, 101) using the mouse under the scale factor 2, and he checked >> (frame-parameter nil 'left)? > Is 101 scaled or unscaled? If scaled, left would be 101. If not > scaled, left would be 50. Loss of precision? Sure, but does it > matter in most cases? Of course scaled. > Another idea would be if Emacs had its own internal coordinate > system, say 0.0 to 1.0 or some integer based one, that already is > display independent. It would fit nicely with the GnomeCanvas idea > (see other thread). A bunch of work though... What would happen to the absolute scaled coordinate system if scaling factors are different from frame to frame? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 05:35:33 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 09:35:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZKqr-0008N5-0l for submit@debbugs.gnu.org; Thu, 15 Jul 2010 05:35:33 -0400 Received: from smtprelay-h21.telenor.se ([195.54.99.196]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZKqo-0008My-Cz for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 05:35:31 -0400 Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-h21.telenor.se (Postfix) with ESMTP id C9758E9C87 for <5721@debbugs.gnu.org>; Thu, 15 Jul 2010 11:35:39 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsM1AJtzPkxV4S0jPGdsb2JhbACHcZd4DAEBAQE1Lb4vhSQEkg0 X-IronPort-AV: E=Sophos;i="4.55,207,1278280800"; d="scan'208";a="104626867" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb2.telenor.se with ESMTP; 15 Jul 2010 11:35:39 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 822C17FA05A; Thu, 15 Jul 2010 11:35:38 +0200 (CEST) Message-ID: <4C3ED669.1020607@swipnet.se> Date: Thu, 15 Jul 2010 11:35:37 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.3 (---) YAMAMOTO Mitsuharu skrev 2010-07-15 11.27: > > Another idea would be if Emacs had its own internal coordinate >> system, say 0.0 to 1.0 or some integer based one, that already is >> display independent. It would fit nicely with the GnomeCanvas idea >> (see other thread). A bunch of work though... > > What would happen to the absolute scaled coordinate system if scaling > factors are different from frame to frame? Placing frames based on the position of another frame is the only operation I can think of that uses coordinates from one frame and applies it to another. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 05:38:51 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 09:38:52 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZKu2-0008OL-VQ for submit@debbugs.gnu.org; Thu, 15 Jul 2010 05:38:51 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZKtz-0008OE-T8 for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 05:38:49 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 8ED33C0557; Thu, 15 Jul 2010 18:38:54 +0900 (JST) Date: Thu, 15 Jul 2010 18:38:54 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C3ED669.1020607@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Thu, 15 Jul 2010 11:35:37 +0200, Jan Dj=E4rv = said: >> What would happen to the absolute scaled coordinate system if >> scaling factors are different from frame to frame? > Placing frames based on the position of another frame is the only > operation I can think of that uses coordinates from one frame and > applies it to another. And you introduce yet another special function for that purpose? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 05:57:48 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 09:57:48 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZLCN-0008WA-9n for submit@debbugs.gnu.org; Thu, 15 Jul 2010 05:57:47 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZLCJ-0008W4-Tp for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 05:57:45 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id BDC82C0557; Thu, 15 Jul 2010 18:57:50 +0900 (JST) Date: Thu, 15 Jul 2010 18:57:50 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C3ED669.1020607@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) It seems to be difficult to reach agreement about absolete unscaled vs. absolute scaled. Fortunately, that doesn't matter for X11 currently, and we agree with the necessity of a special function that returns absolute unscaled coordinates to pass to an external program. Why don't we start discussing the specification of that special function, letting absolute unscaled vs. absolute scaled aside for now? My proposal was to make it parallel to posn-at-x-y, as I mentioned. (posn-at-x-y x y &optional frame-or-window whole) YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 06:32:50 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 10:32:51 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZLkH-0000Ky-FN for submit@debbugs.gnu.org; Thu, 15 Jul 2010 06:32:49 -0400 Received: from smtprelay-b12.telenor.se ([62.127.194.21]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZLkF-0000Ks-0Q for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 06:32:47 -0400 Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-b12.telenor.se (Postfix) with ESMTP id C9A68E9CE9 for <5721@debbugs.gnu.org>; Thu, 15 Jul 2010 12:32:56 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsM1AH6APkxV4S0jPGdsb2JhbACHcZd1DAEBAQE1Lb4FhSQEkg0 X-IronPort-AV: E=Sophos;i="4.55,207,1278280800"; d="scan'208";a="104648106" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb2.telenor.se with ESMTP; 15 Jul 2010 12:32:56 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 6824B7FA05A; Thu, 15 Jul 2010 12:32:55 +0200 (CEST) Message-ID: <4C3EE3D6.4060901@swipnet.se> Date: Thu, 15 Jul 2010 12:32:54 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.3 (---) YAMAMOTO Mitsuharu skrev 2010-07-15 11.38: >>>>>> On Thu, 15 Jul 2010 11:35:37 +0200, Jan Dj=E4rv said: > >>> What would happen to the absolute scaled coordinate system if >>> scaling factors are different from frame to frame? > >> Placing frames based on the position of another frame is the only >> operation I can think of that uses coordinates from one frame and >> applies it to another. > > And you introduce yet another special function for that purpose? I don't know what you mean by "yet another". I already purposed function= s for=20 frame placement by unscaled coords. Why is that such a burdon, but=20 introducing a whole series of parallel functions like pos-x-y et.al isn't= ? Jan D. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 06:56:33 2010 Received: (at 5721) by debbugs.gnu.org; 15 Jul 2010 10:56:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZM7E-0000Vx-Q1 for submit@debbugs.gnu.org; Thu, 15 Jul 2010 06:56:32 -0400 Received: from smtprelay-h31.telenor.se ([213.150.131.4]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZM7C-0000Vq-En for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 06:56:31 -0400 Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-h31.telenor.se (Postfix) with ESMTP id 5822BE9DAD for <5721@debbugs.gnu.org>; Thu, 15 Jul 2010 12:56:40 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsM1AFuGPkxV4S0jPGdsb2JhbACHcZd1DAEBAQE1Lb4QhSQEkg0 X-IronPort-AV: E=Sophos;i="4.55,207,1278280800"; d="scan'208";a="105721098" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb1.telenor.se with ESMTP; 15 Jul 2010 12:56:39 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 951BF7FA05A; Thu, 15 Jul 2010 12:56:39 +0200 (CEST) Message-ID: <4C3EE966.5050704@swipnet.se> Date: Thu, 15 Jul 2010 12:56:38 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) YAMAMOTO Mitsuharu skrev 2010-07-15 11.57: > It seems to be difficult to reach agreement about absolete unscaled > vs. absolute scaled. Fortunately, that doesn't matter for X11 > currently, and we agree with the necessity of a special function that > returns absolute unscaled coordinates to pass to an external program. > Why don't we start discussing the specification of that special > function, letting absolute unscaled vs. absolute scaled aside for now? > > My proposal was to make it parallel to posn-at-x-y, as I mentioned. > > (posn-at-x-y x y&optional frame-or-window whole) > Sure. Please check the ifdefs in the window absolute functions I made to see the various differences w.r.t tool bar and menu bar. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 20:25:29 2010 Received: (at 5721) by debbugs.gnu.org; 16 Jul 2010 00:25:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZYk4-0006lf-7X for submit@debbugs.gnu.org; Thu, 15 Jul 2010 20:25:28 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZYk0-0006lX-84 for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 20:25:25 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id CB151C0557; Fri, 16 Jul 2010 09:25:32 +0900 (JST) Date: Fri, 16 Jul 2010 09:25:32 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C3EE3D6.4060901@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> <4C3EE3D6.4060901@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Thu, 15 Jul 2010 12:32:54 +0200, Jan Dj=E4rv = said: >>> Placing frames based on the position of another frame is the only >>> operation I can think of that uses coordinates from one frame and >>> applies it to another. >>=20 >> And you introduce yet another special function for that purpose? > I don't know what you mean by "yet another". I already purposed > functions for frame placement by unscaled coords. Why is that such > a burdon, but introducing a whole series of parallel functions like > pos-x-y et.al isn't? Neither the frame placement function nor window-(inside-)absolute-pixel-edges is necessary if we use the absolute unscaled coordinate system and introduce a function parallel to pos-x-y, which is anyway necessary for external programs' use. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 20:35:47 2010 Received: (at 5721) by debbugs.gnu.org; 16 Jul 2010 00:35:47 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZYu1-0006q6-T5 for submit@debbugs.gnu.org; Thu, 15 Jul 2010 20:35:46 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZYu0-0006q1-Jk for 5721@debbugs.gnu.org; Thu, 15 Jul 2010 20:35:45 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id A03DEC0557; Fri, 16 Jul 2010 09:35:54 +0900 (JST) Date: Fri, 16 Jul 2010 09:35:54 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C3EE966.5050704@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> <4C3EE966.5050704@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Thu, 15 Jul 2010 12:56:38 +0200, Jan Dj=E4rv = said: >> It seems to be difficult to reach agreement about absolete unscaled >> vs. absolute scaled. Fortunately, that doesn't matter for X11 >> currently, and we agree with the necessity of a special function >> that returns absolute unscaled coordinates to pass to an external >> program. Why don't we start discussing the specification of that >> special function, letting absolute unscaled vs. absolute scaled >> aside for now? >>=20 >> My proposal was to make it parallel to posn-at-x-y, as I mentioned. >>=20 >> (posn-at-x-y x y &optional frame-or-window whole) >>=20 > Sure. Please check the ifdefs in the window absolute functions I > made to see the various differences w.r.t tool bar and menu bar. I don't think such ifdefs are necessary. The strategy I'm thinking of is: 1) Convert window coordinates to frame coordinates if the third argument is not a frame. This should be similar to the code in pos-at-x-y. 2) Call a terminal-specific function that converts frame-relative coordinates to absolute coordinates. That can be done by the following "idiom". x +=3D f->left_pos + FRAME_OUTER_TO_INNER_DIFF_X (f); y +=3D f->top_pos + FRAME_OUTER_TO_INNER_DIFF_Y (f); on X11 and ClientToScreen (FRAME_W32_WINDOW (f), &pt) on W32, I guess. By the way, window-(inside-)absolute-pixel-edges doesn't seem to take account of title bar height. Is that correct? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 16 02:38:44 2010 Received: (at 5721) by debbugs.gnu.org; 16 Jul 2010 06:38:44 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZeZH-0000o7-7m for submit@debbugs.gnu.org; Fri, 16 Jul 2010 02:38:44 -0400 Received: from smtprelay-b11.telenor.se ([62.127.194.20]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZeZE-0000o2-RH for 5721@debbugs.gnu.org; Fri, 16 Jul 2010 02:38:41 -0400 Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-b11.telenor.se (Postfix) with ESMTP id 9B47CEA4F4 for <5721@debbugs.gnu.org>; Fri, 16 Jul 2010 08:38:52 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Avw7AOqaP0xV4S0jPGdsb2JhbACHcJd6DAEBAQE1Lb5QgnAIgiwEkg4 X-IronPort-AV: E=Sophos;i="4.55,213,1278280800"; d="scan'208";a="548442986" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb3.telenor.se with ESMTP; 16 Jul 2010 08:38:47 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 7D6D67FA05A; Fri, 16 Jul 2010 08:38:45 +0200 (CEST) Message-ID: <4C3FFE74.2090602@swipnet.se> Date: Fri, 16 Jul 2010 08:38:44 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> <4C3EE966.5050704@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) YAMAMOTO Mitsuharu skrev 2010-07-16 02.35: >>>>>> On Thu, 15 Jul 2010 12:56:38 +0200, Jan Dj=E4rv said: > >>> It seems to be difficult to reach agreement about absolete unscaled >>> vs. absolute scaled. Fortunately, that doesn't matter for X11 >>> currently, and we agree with the necessity of a special function >>> that returns absolute unscaled coordinates to pass to an external >>> program. Why don't we start discussing the specification of that >>> special function, letting absolute unscaled vs. absolute scaled >>> aside for now? >>> >>> My proposal was to make it parallel to posn-at-x-y, as I mentioned. >>> >>> (posn-at-x-y x y&optional frame-or-window whole) >>> > >> Sure. Please check the ifdefs in the window absolute functions I >> made to see the various differences w.r.t tool bar and menu bar. > > I don't think such ifdefs are necessary. The strategy I'm thinking of > is: > > 1) Convert window coordinates to frame coordinates if the third > argument is not a frame. This should be similar to the code in > pos-at-x-y. AFAIK, there is no pos-at-x-y function. Did you mean posn-at-x-y? > 2) Call a terminal-specific function that converts frame-relative > coordinates to absolute coordinates. That can be done by the > following "idiom". > > x +=3D f->left_pos + FRAME_OUTER_TO_INNER_DIFF_X (f); > y +=3D f->top_pos + FRAME_OUTER_TO_INNER_DIFF_Y (f); > > on X11 and > > ClientToScreen (FRAME_W32_WINDOW (f),&pt) > > on W32, I guess. You left out Nextstep/OSX. > > By the way, window-(inside-)absolute-pixel-edges doesn't seem to take > account of title bar height. Is that correct? Why should it? The titlebar isn't an Emacs window in X, it belongs to th= e=20 window manager. Top/left does not point at it, it points at the Emacs fr= ame. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 16 02:39:28 2010 Received: (at 5721) by debbugs.gnu.org; 16 Jul 2010 06:39:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZea0-0000od-7j for submit@debbugs.gnu.org; Fri, 16 Jul 2010 02:39:28 -0400 Received: from smtprelay-h22.telenor.se ([195.54.99.197]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZeZy-0000oY-Be for 5721@debbugs.gnu.org; Fri, 16 Jul 2010 02:39:27 -0400 Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-h22.telenor.se (Postfix) with ESMTP id 10555EA514 for <5721@debbugs.gnu.org>; Fri, 16 Jul 2010 08:39:37 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Avw7ABecP0xV4S0jPGdsb2JhbACHcJd6DAEBAQE1Lb5RhSQEkg4 X-IronPort-AV: E=Sophos;i="4.55,213,1278280800"; d="scan'208";a="105037389" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb2.telenor.se with ESMTP; 16 Jul 2010 08:39:30 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id BD5907FA05A; Fri, 16 Jul 2010 08:39:28 +0200 (CEST) Message-ID: <4C3FFEA0.7070007@swipnet.se> Date: Fri, 16 Jul 2010 08:39:28 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> <4C3EE3D6.4060901@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) YAMAMOTO Mitsuharu skrev 2010-07-16 02.25: >>>>>> On Thu, 15 Jul 2010 12:32:54 +0200, Jan Dj=E4rv said: > >>>> Placing frames based on the position of another frame is the only >>>> operation I can think of that uses coordinates from one frame and >>>> applies it to another. >>> >>> And you introduce yet another special function for that purpose? > >> I don't know what you mean by "yet another". I already purposed >> functions for frame placement by unscaled coords. Why is that such >> a burdon, but introducing a whole series of parallel functions like >> pos-x-y et.al isn't? > > Neither the frame placement function nor > window-(inside-)absolute-pixel-edges is necessary if we use the > absolute unscaled coordinate system and introduce a function parallel > to pos-x-y, which is anyway necessary for external programs' use. How do you find the difference between inner and outer window edges with = such=20 a function? Jan D. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 16 04:37:32 2010 Received: (at 5721) by debbugs.gnu.org; 16 Jul 2010 08:37:32 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZgQF-0001eo-JA for submit@debbugs.gnu.org; Fri, 16 Jul 2010 04:37:31 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZgQB-0001ej-Ne for 5721@debbugs.gnu.org; Fri, 16 Jul 2010 04:37:29 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id E7AA3C0557; Fri, 16 Jul 2010 17:37:37 +0900 (JST) Date: Fri, 16 Jul 2010 17:37:37 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C3FFE74.2090602@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> <4C3EE966.5050704@swipnet.se> <4C3FFE74.2090602@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Fri, 16 Jul 2010 08:38:44 +0200, Jan Dj=E4rv = said: >> 2) Call a terminal-specific function that converts frame-relative >> coordinates to absolute coordinates. That can be done by the >> following "idiom". >>=20 >> x +=3D f->left_pos + FRAME_OUTER_TO_INNER_DIFF_X (f); y +=3D f->top_pos >> + FRAME_OUTER_TO_INNER_DIFF_Y (f); >>=20 >> on X11 and >>=20 >> ClientToScreen (FRAME_W32_WINDOW (f),&pt) >>=20 >> on W32, I guess. > You left out Nextstep/OSX. I did so because if I coded it correctly, that would become inconsistent with the other part of the NS port. I'd leave it to those who are familiar with the NS port code and design. >> By the way, window-(inside-)absolute-pixel-edges doesn't seem to >> take account of title bar height. Is that correct? > Why should it? The titlebar isn't an Emacs window in X, it belongs > to the window manager. Top/left does not point at it, it points at > the Emacs frame. Is the following the intended behavior? I tested it with Mac OS X 10.6, GTK+ build, the trunk. 1. $ emacs -Q -D -geometry +100+100 & 2. (frame-parameter nil 'top) C-j =3D> 100 3. (window-absolute-pixel-edges) C-j =3D> (100 100 756 678) YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 16 04:48:56 2010 Received: (at 5721) by debbugs.gnu.org; 16 Jul 2010 08:48:56 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZgbH-0001jr-8W for submit@debbugs.gnu.org; Fri, 16 Jul 2010 04:48:55 -0400 Received: from smtprelay-b11.telenor.se ([62.127.194.20]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZgbE-0001jm-EJ for 5721@debbugs.gnu.org; Fri, 16 Jul 2010 04:48:53 -0400 Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-b11.telenor.se (Postfix) with ESMTP id 8163BEA47C for <5721@debbugs.gnu.org>; Fri, 16 Jul 2010 10:49:04 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Avw7AGK5P0xV4S0jPGdsb2JhbACHcJd0DAEBAQE1Lb4mgnAIgiwEkg4 X-IronPort-AV: E=Sophos;i="4.55,213,1278280800"; d="scan'208";a="106148403" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb1.telenor.se with ESMTP; 16 Jul 2010 10:49:04 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 754EE7FA05A; Fri, 16 Jul 2010 10:49:03 +0200 (CEST) Message-ID: <4C401CFD.3020306@swipnet.se> Date: Fri, 16 Jul 2010 10:49:01 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> <4C3EE966.5050704@swipnet.se> <4C3FFE74.2090602@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) YAMAMOTO Mitsuharu skrev 2010-07-16 10.37: >>>>>> On Fri, 16 Jul 2010 08:38:44 +0200, Jan Dj=E4rv said: >>> By the way, window-(inside-)absolute-pixel-edges doesn't seem to >>> take account of title bar height. Is that correct? > >> Why should it? The titlebar isn't an Emacs window in X, it belongs >> to the window manager. Top/left does not point at it, it points at >> the Emacs frame. > > Is the following the intended behavior? I tested it with Mac OS X > 10.6, GTK+ build, the trunk. > > 1. $ emacs -Q -D -geometry +100+100& > 2. (frame-parameter nil 'top) C-j > =3D> 100 > 3. (window-absolute-pixel-edges) C-j > =3D> (100 100 756 678) > That depends on your window manager. If I do the same command, I get 'to= p=20 equal to 124, as the title bar is 24 pixels high and the window manager=20 (Compiz) puts the top of the title bar at 100. Other window managers may= =20 choose to put the Emacs window at 100 and the title bar above that. It i= sn't=20 defined what a window manager should do. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 16 04:58:22 2010 Received: (at 5721) by debbugs.gnu.org; 16 Jul 2010 08:58:22 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZgkP-0001o2-9U for submit@debbugs.gnu.org; Fri, 16 Jul 2010 04:58:21 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZgkM-0001nx-5z for 5721@debbugs.gnu.org; Fri, 16 Jul 2010 04:58:19 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id CFBDEC0557; Fri, 16 Jul 2010 17:58:27 +0900 (JST) Date: Fri, 16 Jul 2010 17:58:27 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C401CFD.3020306@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> <4C3EE966.5050704@swipnet.se> <4C3FFE74.2090602@swipnet.se> <4C401CFD.3020306@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Fri, 16 Jul 2010 10:49:01 +0200, Jan Dj=E4rv = said: > That depends on your window manager. If I do the same command, I get 'to= p=20 > equal to 124, as the title bar is 24 pixels high and the window > manager (Compiz) puts the top of the title bar at 100. Other window > managers may choose to put the Emacs window at 100 and the title bar > above that. It isn't defined what a window manager should do. I also checked that CDE's window manager behaves like Mac OS X's, i.e., left/top frame parameters points to the title bar. You mean one can specify the position of the top-left corner of the title bar with the geometry specification, but that cannot reliably be done with left/top frame parameters? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 16 05:14:18 2010 Received: (at 5721) by debbugs.gnu.org; 16 Jul 2010 09:14:18 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZgzq-0001v5-BM for submit@debbugs.gnu.org; Fri, 16 Jul 2010 05:14:18 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZgzn-0001v0-KK for 5721@debbugs.gnu.org; Fri, 16 Jul 2010 05:14:17 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 3A834C0557; Fri, 16 Jul 2010 18:14:25 +0900 (JST) Date: Fri, 16 Jul 2010 18:14:25 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C3FFEA0.7070007@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> <4C3EE3D6.4060901@swipnet.se> <4C3FFEA0.7070007@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Fri, 16 Jul 2010 08:39:28 +0200, Jan Dj=E4rv = said: > How do you find the difference between inner and outer window edges > with such a function? I think the primary intention of the left/top frame parameters are coordinates of the top-left corner of the title bar, because x_set_offset basically sets the outer window's position to f->left_pos, and f->top_pos. That is also consistent with the geometry specification. In that case, the difference can be computed from these frame parameters and the absolute coordinates of top-left corner of the frame. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 16 08:19:13 2010 Received: (at 5721) by debbugs.gnu.org; 16 Jul 2010 12:19:13 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZjsm-0004SH-I6 for submit@debbugs.gnu.org; Fri, 16 Jul 2010 08:19:12 -0400 Received: from smtprelay-b11.telenor.se ([62.127.194.20]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZjsk-0004SB-SB for 5721@debbugs.gnu.org; Fri, 16 Jul 2010 08:19:11 -0400 Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-b11.telenor.se (Postfix) with ESMTP id 5EE8DEA61E for <5721@debbugs.gnu.org>; Fri, 16 Jul 2010 14:19:23 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq1BAJrqP0xV4S0jPGdsb2JhbACHcJd3DAEBAQE1Lb4WhSQEkg4 X-IronPort-AV: E=Sophos;i="4.55,214,1278280800"; d="scan'208";a="548561229" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb3.telenor.se with ESMTP; 16 Jul 2010 14:19:22 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 1086A7FA05A; Fri, 16 Jul 2010 14:19:22 +0200 (CEST) Message-ID: <4C404E49.1050101@swipnet.se> Date: Fri, 16 Jul 2010 14:19:21 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> <4C3EE966.5050704@swipnet.se> <4C3FFE74.2090602@swipnet.se> <4C401CFD.3020306@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) YAMAMOTO Mitsuharu skrev 2010-07-16 10.58: >>>>>> On Fri, 16 Jul 2010 10:49:01 +0200, Jan Dj=E4rv said: > >> That depends on your window manager. If I do the same command, I get = 'top >> equal to 124, as the title bar is 24 pixels high and the window >> manager (Compiz) puts the top of the title bar at 100. Other window >> managers may choose to put the Emacs window at 100 and the title bar >> above that. It isn't defined what a window manager should do. > > I also checked that CDE's window manager behaves like Mac OS X's, > i.e., left/top frame parameters points to the title bar. > > You mean one can specify the position of the top-left corner of the > title bar with the geometry specification, but that cannot reliably be > done with left/top frame parameters? When there is a window manager present, no move or resize can be done=20 reliably. The window manager is free to modify them. Some don't allow m= ove=20 partly offscreen, some do. Some don't allow move over the gnome-panel, s= ome do. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 16 08:20:49 2010 Received: (at 5721) by debbugs.gnu.org; 16 Jul 2010 12:20:49 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZjuL-0004T1-1M for submit@debbugs.gnu.org; Fri, 16 Jul 2010 08:20:49 -0400 Received: from smtprelay-b12.telenor.se ([62.127.194.21]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZjuI-0004Sv-Ll for 5721@debbugs.gnu.org; Fri, 16 Jul 2010 08:20:47 -0400 Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-b12.telenor.se (Postfix) with ESMTP id 6855DEA1F6 for <5721@debbugs.gnu.org>; Fri, 16 Jul 2010 14:20:59 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq1BAMfrP0xV4S0jPGdsb2JhbACHcJd3DAEBAQE1Lb4jhSQEkg4 X-IronPort-AV: E=Sophos;i="4.55,214,1278280800"; d="scan'208";a="106222326" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb1.telenor.se with ESMTP; 16 Jul 2010 14:20:59 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 480F67FA05A; Fri, 16 Jul 2010 14:20:58 +0200 (CEST) Message-ID: <4C404EAA.20108@swipnet.se> Date: Fri, 16 Jul 2010 14:20:58 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> <4C3EE3D6.4060901@swipnet.se> <4C3FFEA0.7070007@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.3 (---) YAMAMOTO Mitsuharu skrev 2010-07-16 11.14: >>>>>> On Fri, 16 Jul 2010 08:39:28 +0200, Jan Dj=E4rv said: > >> How do you find the difference between inner and outer window edges >> with such a function? > > I think the primary intention of the left/top frame parameters are > coordinates of the top-left corner of the title bar, because > x_set_offset basically sets the outer window's position to > f->left_pos, and f->top_pos. That is also consistent with the > geometry specification. In that case, the difference can be computed > from these frame parameters and the absolute coordinates of top-left > corner of the frame. This is not reliable. Window managers may put decorations on the side, t= hese=20 should not be counted. Besides, left_pos and top_pos is not the corners = of=20 the title bar under X. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 16 20:30:36 2010 Received: (at 5721) by debbugs.gnu.org; 17 Jul 2010 00:30:36 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZvIZ-00036z-Nb for submit@debbugs.gnu.org; Fri, 16 Jul 2010 20:30:36 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZvIW-00036u-OV for 5721@debbugs.gnu.org; Fri, 16 Jul 2010 20:30:34 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 02BC6C0557; Sat, 17 Jul 2010 09:30:44 +0900 (JST) Date: Sat, 17 Jul 2010 09:30:43 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C404E49.1050101@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> <4C3EE966.5050704@swipnet.se> <4C3FFE74.2090602@swipnet.se> <4C401CFD.3020306@swipnet.se> <4C404E49.1050101@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, IRIE Shinsuke X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Fri, 16 Jul 2010 14:19:21 +0200, Jan Dj=E4rv = said: >>> That depends on your window manager. If I do the same command, I >>> get 'top equal to 124, as the title bar is 24 pixels high and the >>> window manager (Compiz) puts the top of the title bar at 100. >>> Other window managers may choose to put the Emacs window at 100 >>> and the title bar above that. It isn't defined what a window >>> manager should do. >>=20 >> I also checked that CDE's window manager behaves like Mac OS X's, >> i.e., left/top frame parameters points to the title bar. >>=20 >> You mean one can specify the position of the top-left corner of the >> title bar with the geometry specification, but that cannot reliably >> be done with left/top frame parameters? > When there is a window manager present, no move or resize can be > done reliably. The window manager is free to modify them. Some > don't allow move partly offscreen, some do. Some don't allow move > over the gnome-panel, some do. In that case, Emacs is supposed to adjust left/top frame parameters according to the title-bar top-left corner position that the window manager modified, in response to some notification events. Even with Compiz, left/top frame parameters point to the title bar if we turn off visual effects. I tested it with Ubuntu 10.04. I suspect x_real_positions fails to get the window for decoration for Compiz if visual effects are turned on. Maybe Compiz does not assign X11 windows for window decorations. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 17 01:32:06 2010 Received: (at 5721) by debbugs.gnu.org; 17 Jul 2010 05:32:07 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oa00M-0004uu-4X for submit@debbugs.gnu.org; Sat, 17 Jul 2010 01:32:06 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oa00J-0004uY-Ax for 5721@debbugs.gnu.org; Sat, 17 Jul 2010 01:32:04 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 4E53DC0560; Sat, 17 Jul 2010 14:32:15 +0900 (JST) Date: Sat, 17 Jul 2010 14:32:15 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: References: <4B9E4521.9030909@yahoo.co.jp> <4C2C8C02.1010906@swipnet.se> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> <4C3EE966.5050704@swipnet.se> <4C3FFE74.2090602@swipnet.se> <4C401CFD.3020306@swipnet.se> <4C404E49.1050101@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Sat, 17 Jul 2010 09:30:43 +0900, YAMAMOTO Mitsuharu said: > Even with Compiz, left/top frame parameters point to the title bar > if we turn off visual effects. I tested it with Ubuntu 10.04. > I suspect x_real_positions fails to get the window for decoration > for Compiz if visual effects are turned on. Maybe Compiz does not > assign X11 windows for window decorations. As far as I tested with xprop and xwininfo, _NET_FRAME_WINDOW and/or _NET_[REQUEST_]FRAME_EXTENTS seem to be useful for x_real_positions to do the documented job. (Though I could not find the former in EWMH.) /* Store the screen positions of frame F into XPTR and YPTR. These are the positions of the containing window manager window, not Emacs's own window. */ YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 17 04:36:48 2010 Received: (at 5721) by debbugs.gnu.org; 17 Jul 2010 08:36:48 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oa2t6-00060f-BM for submit@debbugs.gnu.org; Sat, 17 Jul 2010 04:36:48 -0400 Received: from smtprelay-h32.telenor.se ([213.150.131.5]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oa2t4-0005zl-CM for 5721@debbugs.gnu.org; Sat, 17 Jul 2010 04:36:47 -0400 Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-h32.telenor.se (Postfix) with ESMTP id AE609E9467 for <5721@debbugs.gnu.org>; Sat, 17 Jul 2010 10:37:01 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmY7AIsIQUxV4S0jPGdsb2JhbACHcpd7DAEBAQE1Lb84hSUEkhg X-IronPort-AV: E=Sophos;i="4.55,218,1278280800"; d="scan'208";a="548946048" Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb3.telenor.se with ESMTP; 17 Jul 2010 10:37:01 +0200 Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id C78E57FA05A; Sat, 17 Jul 2010 10:37:00 +0200 (CEST) Message-ID: <4C416BAC.3020202@swipnet.se> Date: Sat, 17 Jul 2010 10:37:00 +0200 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: YAMAMOTO Mitsuharu Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> <4C3EE966.5050704@swipnet.se> <4C3FFE74.2090602@swipnet.se> <4C401CFD.3020306@swipnet.se> <4C404E49.1050101@swipnet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) YAMAMOTO Mitsuharu skrev 2010-07-17 07.32: >>>>>> On Sat, 17 Jul 2010 09:30:43 +0900, YAMAMOTO Mitsuharu said: > >> Even with Compiz, left/top frame parameters point to the title bar >> if we turn off visual effects. I tested it with Ubuntu 10.04. > >> I suspect x_real_positions fails to get the window for decoration >> for Compiz if visual effects are turned on. Maybe Compiz does not >> assign X11 windows for window decorations. There are no other windows than X windows... But the parent-child relationship may be different. > > As far as I tested with xprop and xwininfo, _NET_FRAME_WINDOW and/or > _NET_[REQUEST_]FRAME_EXTENTS seem to be useful for x_real_positions to > do the documented job. (Though I could not find the former in EWMH.) Not portable for all window managers so we have to keep the old way anyway. _NET_REQUEST_FRAME_EXTENTS is in version 1.4 of EWMH. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 17 04:42:09 2010 Received: (at 5721) by debbugs.gnu.org; 17 Jul 2010 08:42:09 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oa2yG-00063H-VJ for submit@debbugs.gnu.org; Sat, 17 Jul 2010 04:42:09 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oa2yC-00062v-Vx for 5721@debbugs.gnu.org; Sat, 17 Jul 2010 04:42:06 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 5F6C3C0560; Sat, 17 Jul 2010 17:42:19 +0900 (JST) Date: Sat, 17 Jul 2010 17:42:19 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-Reply-To: <4C416BAC.3020202@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <4C2D9009.60405@swipnet.se> <4C3DD633.7040004@swipnet.se> <4C3EA59E.40300@swipnet.se> <4C3EBDAD.1040800@swipnet.se> <4C3EC17E.6060101@swipnet.se> <4C3EC863.3030803@swipnet.se> <4C3ECE08.2040604@swipnet.se> <4C3ED669.1020607@swipnet.se> <4C3EE966.5050704@swipnet.se> <4C3FFE74.2090602@swipnet.se> <4C401CFD.3020306@swipnet.se> <4C404E49.1050101@swipnet.se> <4C416BAC.3020202@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) >>>>> On Sat, 17 Jul 2010 10:37:00 +0200, Jan Dj=E4rv = said: >>> I suspect x_real_positions fails to get the window for decoration >>> for Compiz if visual effects are turned on. Maybe Compiz does not >>> assign X11 windows for window decorations. > There are no other windows than X windows... But the parent-child > relationship may be different. Yes actually there was a window-id that was obtained with _NET_FRAME_WINDOW. >> As far as I tested with xprop and xwininfo, _NET_FRAME_WINDOW >> and/or _NET_[REQUEST_]FRAME_EXTENTS seem to be useful for >> x_real_positions to do the documented job. (Though I could not >> find the former in EWMH.) > Not portable for all window managers so we have to keep the old way > anyway. _NET_REQUEST_FRAME_EXTENTS is in version 1.4 of EWMH. Yes, of course I meant try _NET_* first, and fall back on the old way if not available. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From unknown Wed Jun 25 09:13:09 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 14 Aug 2010 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 13 19:46:12 2013 Received: (at control) by debbugs.gnu.org; 14 Jan 2013 00:46:12 +0000 Received: from localhost ([127.0.0.1]:58845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TuYBn-0008T4-35 for submit@debbugs.gnu.org; Sun, 13 Jan 2013 19:46:11 -0500 Received: from gateway-b.fh-trier.de ([143.93.54.182]:58930) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TuU6I-0002EP-W0 for control@debbugs.gnu.org; Sun, 13 Jan 2013 15:24:15 -0500 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier] Received: from hochschule-trier.de (owm2.fh-trier.de [143.93.54.169]) by gateway-b.fh-trier.de (Postfix) with ESMTP id 7104317B470 for ; Sun, 13 Jan 2013 21:23:34 +0100 (CET) From: "Andreas Politz, INF|INF-I" To: control@debbugs.gnu.org Subject: N/A Date: Sun, 13 Jan 2013 21:23:34 +0100 Message-Id: <20130113202040.M27340@hochschule-trier.de> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 88.68.49.7 (politza) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Spam-Score: -1.5 (-) X-Debbugs-Envelope-To: control X-Mailman-Approved-At: Sun, 13 Jan 2013 19:46:09 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.5 (-) unarchive 5721 From unknown Wed Jun 25 09:13:09 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 11 Feb 2013 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 28 14:05:10 2013 Received: (at control) by debbugs.gnu.org; 28 Sep 2013 18:05:10 +0000 Received: from localhost ([127.0.0.1]:43394 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VPytB-0001Bi-Ip for submit@debbugs.gnu.org; Sat, 28 Sep 2013 14:05:09 -0400 Received: from gateway-b.fh-trier.de ([143.93.54.182]:42305) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VPyt8-0001BX-Lm for control@debbugs.gnu.org; Sat, 28 Sep 2013 14:05:07 -0400 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier] Received: from luca (dslb-178-004-164-059.pools.arcor-ip.net [178.4.164.59]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-b.fh-trier.de (Postfix) with ESMTPSA id 82D7817B4A4 for ; Sat, 28 Sep 2013 20:04:50 +0200 (CEST) Received: from politza by luca with local (Exim 4.72) (envelope-from ) id 1VPysr-0008LD-P2 for control@debbugs.gnu.org; Sat, 28 Sep 2013 20:04:49 +0200 From: Andreas Politz To: control@debbugs.gnu.org Subject: unarchive 5721 Date: Sat, 28 Sep 2013 20:04:49 +0200 Message-ID: <87k3i0esam.fsf@hochschule-trier.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) unarchive 5721 From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 28 16:06:59 2013 Received: (at 5721) by debbugs.gnu.org; 28 Sep 2013 20:07:00 +0000 Received: from localhost ([127.0.0.1]:43612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQ0n5-00057H-Dt for submit@debbugs.gnu.org; Sat, 28 Sep 2013 16:06:59 -0400 Received: from gateway-a.fh-trier.de ([143.93.54.181]:59141) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQ0n3-000579-HI for 5721@debbugs.gnu.org; Sat, 28 Sep 2013 16:06:58 -0400 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier] Received: from luca (dslb-178-004-164-059.pools.arcor-ip.net [178.4.164.59]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-a.fh-trier.de (Postfix) with ESMTPSA id 363B41761162 for <5721@debbugs.gnu.org>; Sat, 28 Sep 2013 22:06:41 +0200 (CEST) Received: from politza by luca with local (Exim 4.72) (envelope-from ) id 1VQ0mm-0004FY-Go for 5721@debbugs.gnu.org; Sat, 28 Sep 2013 22:06:40 +0200 From: Andreas Politz To: 5721@debbugs.gnu.org Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates Date: Sat, 28 Sep 2013 22:06:40 +0200 Message-ID: <87fvsoemnj.fsf@hochschule-trier.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 5721 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain I'd like the request to be reopened, because the current function `window-inside-absolute-pixel-edges' does not provide the requested behaviour. Suppose no fringes, and header-line. All considerations for a GTK build. 0--------------------------------------* | display | | A----------------------------+ | | | emacs@foo.bar + | | |-B------------------------+ + | | | | toolbar | | | | | +------------------------+ | | | | | menubar | | | | | C------------------------+ | | | | | | | | | | | window | | | | | | D---------+ | | | | | | | tooltip | | | | | | | +---------+ | | | | | +------------------------+ | | | *----------------------------* | | | *--------------------------------------* We have a buffer position D = (D.x, D.y) in some window and want to display a tool-tip there. At the moment, (posn-x-y (posn-at-point)) gives us a position relative to C, so we would need it's absolute position. But `window-absolute-pixel-edges' gives the absolute position of (C.x - (B.x - A.x), C.y - (B.y - A.y)) = (A.x , C.y - (B.y - A.y)) , that is, it does not account for the width and height (B - A) of the window managers decorations. Furthermore these sizes are unknown to the lisp side, making it impossible to complete the desired task. So it seems to me that `window-absolute-pixel-edges' should return the absolute position of C, such that the tool-tip (or other frame) may be positioned at C + D. I noticed, that the frame struct already has members x_pixels_diff and y_pixels_diff, such that (x_pixels_diff, y_pixels_diff) = (B.x - A.x, B.y - A.y) , such that we may compute C with this values. So I propose extending `calc_absolute_offset' by adding these pixel_diff values. For GTK this appears to be especially easy, since these diff values already account for the tool-bar and menu-bar sizes. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=winabs.diff === modified file 'src/window.c' *** src/window.c 2013-09-20 15:34:36 +0000 --- src/window.c 2013-09-28 19:53:08 +0000 *************** *** 939,945 **** calc_absolute_offset (struct window *w, int *add_x, int *add_y) { struct frame *f = XFRAME (w->frame); ! *add_y = f->top_pos; #ifdef FRAME_MENUBAR_HEIGHT *add_y += FRAME_MENUBAR_HEIGHT (f); #endif --- 939,946 ---- calc_absolute_offset (struct window *w, int *add_x, int *add_y) { struct frame *f = XFRAME (w->frame); ! *add_y = f->top_pos + f->y_pixels_diff; ! #ifndef USE_GTK #ifdef FRAME_MENUBAR_HEIGHT *add_y += FRAME_MENUBAR_HEIGHT (f); #endif *************** *** 951,960 **** #ifdef FRAME_NS_TITLEBAR_HEIGHT *add_y += FRAME_NS_TITLEBAR_HEIGHT (f); #endif ! *add_x = f->left_pos; #ifdef FRAME_TOOLBAR_LEFT_WIDTH *add_x += FRAME_TOOLBAR_LEFT_WIDTH (f); #endif } DEFUN ("window-absolute-pixel-edges", Fwindow_absolute_pixel_edges, --- 952,965 ---- #ifdef FRAME_NS_TITLEBAR_HEIGHT *add_y += FRAME_NS_TITLEBAR_HEIGHT (f); #endif ! #endif ! ! *add_x = f->left_pos + f->x_pixels_diff; ! #ifndef USE_GTK #ifdef FRAME_TOOLBAR_LEFT_WIDTH *add_x += FRAME_TOOLBAR_LEFT_WIDTH (f); #endif + #endif } DEFUN ("window-absolute-pixel-edges", Fwindow_absolute_pixel_edges, --=-=-= Content-Type: text/plain After applying the patch, the following function displays a tool-tip below the cursor in the current buffer, which is something that is not possible at the moment (without referring to e.g. xwininfo as the OP explained). (defun tooltip-below-point (msg) (let* ((win-pos (posn-x-y (posn-at-point))) (offset (let ((e (window-inside-absolute-pixel-edges))) (cons (car e) (cadr e)))) (char-y-offset (cdr (posn-object-width-height (posn-at-point)))) (abs-pos (cons (+ (car win-pos) (car offset)) (+ (cdr win-pos) (cdr offset) char-y-offset))) (tooltip-frame-parameters `((left . ,(car abs-pos)) (top . ,(cdr abs-pos))))) (tooltip-show msg))) -ap --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 06:26:52 2013 Received: (at 5721) by debbugs.gnu.org; 29 Sep 2013 10:26:52 +0000 Received: from localhost ([127.0.0.1]:44442 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQEDC-0000FY-72 for submit@debbugs.gnu.org; Sun, 29 Sep 2013 06:26:50 -0400 Received: from mout.gmx.net ([212.227.15.19]:63404) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQED8-0000FM-DB for 5721@debbugs.gnu.org; Sun, 29 Sep 2013 06:26:47 -0400 Received: from [62.47.43.39] ([62.47.43.39]) by mail.gmx.com (mrgmx002) with ESMTPA (Nemesis) id 0M08ia-1VgwkS3s0C-00uJs0 for <5721@debbugs.gnu.org>; Sun, 29 Sep 2013 12:26:45 +0200 Message-ID: <52480060.7020309@gmx.at> Date: Sun, 29 Sep 2013 12:26:40 +0200 From: martin rudalics MIME-Version: 1.0 To: Andreas Politz Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> In-Reply-To: <87fvsoemnj.fsf@hochschule-trier.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:vWqSuCI0HZT/VS6v8H4jsHxjRS1OCON9oGPle9GdhuuLEHPZfOX TRzHwPPj5uXIOvIlKi4aNYWJLJ5W/UHJafABbot+GwJf4iKmwSCKSCSrHfVNHXbqGG0QmSN VHm19hqt2jkXnmtIXIiW4n9IJAKTz93UFZp8NeulJxpHbjFD+w0payMQU4Jp0weXTfyXDwE EnN/gGTGvqWMJby7FgvRQ== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > I'd like the request to be reopened, because the current function > `window-inside-absolute-pixel-edges' does not provide the requested > behaviour. I think your analysis is correct but will leave it to Jan to decide how to proceed. > Suppose no fringes, and header-line. All considerations for a GTK build. > > 0--------------------------------------* > | display | > | A----------------------------+ | > | | emacs@foo.bar + | > | |-B------------------------+ + | > | | | toolbar | | | > | | +------------------------+ | | > | | | menubar | | | > | | C------------------------+ | | > | | | | | | > | | | window | | | > | | | D---------+ | | | > | | | | tooltip | | | | > | | | +---------+ | | | > | | +------------------------+ | | > | *----------------------------* | > | | > *--------------------------------------* Where did/do we put the internal borders of the frame? > We have a buffer position D = > (D.x, D.y) in some window and want to display a tool-tip there. At the > moment, > > (posn-x-y (posn-at-point)) > > gives us a position relative to C, so we would need it's absolute > position. > > But `window-absolute-pixel-edges' gives the absolute position of > > (C.x - (B.x - A.x), C.y - (B.y - A.y)) > = (A.x , C.y - (B.y - A.y)) , > > that is, it does not account for the width and height (B - A) of the > window managers decorations. Furthermore these sizes are unknown to the > lisp side, making it impossible to complete the desired task. I'm not sure whether we can correctly retrieve the decorations always and everywhere. But note that for maximized and full-screen frames there usually are no outer borders and with full-screen frames there's no titlebar either. How does your patch handle these? > So it seems to me that `window-absolute-pixel-edges' should return the > absolute position of C, such that the tool-tip (or other frame) may be > positioned at C + D. > > I noticed, that the frame struct already has members x_pixels_diff and > y_pixels_diff, such that > > (x_pixels_diff, y_pixels_diff) = (B.x - A.x, B.y - A.y) , > > such that we may compute C with this values. So I propose extending > `calc_absolute_offset' by adding these pixel_diff values. For GTK this > appears to be especially easy, since these diff values already account > for the tool-bar and menu-bar sizes. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 11:42:13 2013 Received: (at 5721) by debbugs.gnu.org; 29 Sep 2013 15:42:13 +0000 Received: from localhost ([127.0.0.1]:44944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQJ8P-0001LE-0B for submit@debbugs.gnu.org; Sun, 29 Sep 2013 11:42:13 -0400 Received: from gateway-b.fh-trier.de ([143.93.54.182]:52272) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQJ8M-0001L5-Sc for 5721@debbugs.gnu.org; Sun, 29 Sep 2013 11:42:12 -0400 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier] Received: from luca (dslb-084-059-253-081.pools.arcor-ip.net [84.59.253.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-b.fh-trier.de (Postfix) with ESMTPSA id 6BB8817B4B0; Sun, 29 Sep 2013 17:41:54 +0200 (CEST) Received: from politza by luca with local (Exim 4.72) (envelope-from ) id 1VQJ85-000460-M9; Sun, 29 Sep 2013 17:41:53 +0200 From: Andreas Politz To: martin rudalics Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> Date: Sun, 29 Sep 2013 17:41:53 +0200 In-Reply-To: <52480060.7020309@gmx.at> (martin rudalics's message of "Sun, 29 Sep 2013 12:26:40 +0200") Message-ID: <87mwmvtz26.fsf@hochschule-trier.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) martin rudalics writes: > I'm not sure whether we can correctly retrieve the decorations always > and everywhere. It seems to me, that x_real_positions (xfns.c) does the right thing independent of the WM, i.e. it searches the last parent before the root Window, assumes that it is the outermost Window of the frame and computes the difference to the inner Emacs window (FRAME_X_WINDOW). > But note that for maximized and full-screen frames there usually are > no outer borders and with full-screen frames there's no titlebar > either. How does your patch handle these? > The patch isn't perfect, as in I only tested it with GTK. Are you talking about the frame parameter `border-width' or `internal-border-width' ? I think, as long as we can now the absolute position of (the window at) C, this should probably make no difference, since it shouldn't matter how much of the space of (C - A) is spent on the border or a title (?). The patch works for me with GTK, with internal-border-width and full-screen set, with Xmonad as well as fluxbox. `border-width' in make-frame does not seem to make any difference, it's probably set via a GTK style (?). Anyway the only problem I sometimes ran into is a race condition, resulting in y_pixels_diff being to small. But this is only temporarily until I move the frame, i.e. x_real_positions gets called and is most likely due to GTK windows bee-ing only partially mapped. I think we can figure this out, when it becomes clear, which absolute position `window-absolute-pixel-edges' should actually return. I think it should be C. -ap From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 11:59:11 2013 Received: (at 5721) by debbugs.gnu.org; 29 Sep 2013 15:59:11 +0000 Received: from localhost ([127.0.0.1]:44961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQJOo-0001kB-4x for submit@debbugs.gnu.org; Sun, 29 Sep 2013 11:59:10 -0400 Received: from mail01.bdtv.se ([176.10.222.34]:33703) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1VQJOl-0001jz-6N for 5721@debbugs.gnu.org; Sun, 29 Sep 2013 11:59:08 -0400 Received: (qmail 1157 invoked by uid 89); 29 Sep 2013 15:59:04 -0000 Received: from h-46-59-42-57.na.cust.bahnhof.se (HELO coolsville.localdomain) (boel.djarv@bdtv.se@46.59.42.57) by mail01.bdtv.se with ESMTPA; 29 Sep 2013 15:59:04 -0000 Received: from [172.20.199.13] (unknown [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 74F4D1A01FF; Sun, 29 Sep 2013 15:59:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates From: =?iso-8859-1?Q?Jan_Dj=E4rv?= In-Reply-To: <52480060.7020309@gmx.at> Date: Sun, 29 Sep 2013 17:59:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> To: martin rudalics X-Mailer: Apple Mail (2.1510) X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, Andreas Politz X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) 29 sep 2013 kl. 12:26 skrev martin rudalics : > > I'd like the request to be reopened, because the current function > > `window-inside-absolute-pixel-edges' does not provide the requested > > behaviour. >=20 > I think your analysis is correct but will leave it to Jan to decide = how > to proceed. >=20 I gave no opinion in the matter. I think it is a mistake to let users = access pixels. It worked fine with X and no toolkit or Lucid/Motif. = But nowdays, window manager do strange things and so does toolkits (Gtk+ = don't create separate windows for its widgets for example), so it is = almost impossible to get right.=20 Jan D. > > Suppose no fringes, and header-line. All considerations for a GTK = build. > > > > 0--------------------------------------* > > | display | > > | A----------------------------+ | > > | | emacs@foo.bar + | > > | |-B------------------------+ + | > > | | | toolbar | | | > > | | +------------------------+ | | > > | | | menubar | | | > > | | C------------------------+ | | > > | | | | | | > > | | | window | | | > > | | | D---------+ | | | > > | | | | tooltip | | | | > > | | | +---------+ | | | > > | | +------------------------+ | | > > | *----------------------------* | > > | | > > *--------------------------------------* >=20 > Where did/do we put the internal borders of the frame? >=20 > > We have a buffer position D =3D > > (D.x, D.y) in some window and want to display a tool-tip there. At = the > > moment, > > > > (posn-x-y (posn-at-point)) > > > > gives us a position relative to C, so we would need it's absolute > > position. > > > > But `window-absolute-pixel-edges' gives the absolute position of > > > > (C.x - (B.x - A.x), C.y - (B.y - A.y)) > > =3D (A.x , C.y - (B.y - A.y)) , > > > > that is, it does not account for the width and height (B - A) of the > > window managers decorations. Furthermore these sizes are unknown to = the > > lisp side, making it impossible to complete the desired task. >=20 > I'm not sure whether we can correctly retrieve the decorations always > and everywhere. But note that for maximized and full-screen frames > there usually are no outer borders and with full-screen frames there's > no titlebar either. How does your patch handle these? >=20 > > So it seems to me that `window-absolute-pixel-edges' should return = the > > absolute position of C, such that the tool-tip (or other frame) may = be > > positioned at C + D. > > > > I noticed, that the frame struct already has members x_pixels_diff = and > > y_pixels_diff, such that > > > > (x_pixels_diff, y_pixels_diff) =3D (B.x - A.x, B.y - A.y) , > > > > such that we may compute C with this values. So I propose extending > > `calc_absolute_offset' by adding these pixel_diff values. For GTK = this > > appears to be especially easy, since these diff values already = account > > for the tool-bar and menu-bar sizes. >=20 > martin >=20 >=20 From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 12:02:54 2013 Received: (at 5721) by debbugs.gnu.org; 29 Sep 2013 16:02:54 +0000 Received: from localhost ([127.0.0.1]:44969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQJSP-0001qq-A6 for submit@debbugs.gnu.org; Sun, 29 Sep 2013 12:02:53 -0400 Received: from mail01.bdtv.se ([176.10.222.34]:33719) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1VQJSM-0001qh-Vi for 5721@debbugs.gnu.org; Sun, 29 Sep 2013 12:02:51 -0400 Received: (qmail 1448 invoked by uid 89); 29 Sep 2013 16:02:50 -0000 Received: from h-46-59-42-57.na.cust.bahnhof.se (HELO coolsville.localdomain) (boel.djarv@bdtv.se@46.59.42.57) by mail01.bdtv.se with ESMTPA; 29 Sep 2013 16:02:50 -0000 Received: from [172.20.199.13] (unknown [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id DB3EF1A01EC; Sun, 29 Sep 2013 16:02:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates From: =?iso-8859-1?Q?Jan_Dj=E4rv?= In-Reply-To: <87mwmvtz26.fsf@hochschule-trier.de> Date: Sun, 29 Sep 2013 18:02:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> To: Andreas Politz X-Mailer: Apple Mail (2.1510) X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 5721 Cc: martin rudalics , 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) Hello. 29 sep 2013 kl. 17:41 skrev Andreas Politz = : > martin rudalics writes: >=20 >> I'm not sure whether we can correctly retrieve the decorations always >> and everywhere. >=20 > It seems to me, that x_real_positions (xfns.c) does the right thing > independent of the WM, i.e. it searches the last parent before the = root > Window, assumes that it is the outermost Window of the frame and > computes the difference to the inner Emacs window (FRAME_X_WINDOW). >=20 This is known to be wrong. For example, if some Gtk+ version does = create separate X windows for menu bar and tool bar, the approach gives = the offset to the Emacs text area below the tool bar. If Gtk+ does NOT use separate windows for the menu- and/or tool-bar, but = instead uses the FRAME_X_WINDOW, you get the coordinates to the menu- = and/or tool bar. >=20 > The patch works for me with GTK, with internal-border-width and > full-screen set, with Xmonad as well as fluxbox. `border-width' in > make-frame does not seem to make any difference, it's probably set via = a > GTK style (?). Anyway the only problem I sometimes ran into is a race > condition, resulting in y_pixels_diff being to small. But this is = only > temporarily until I move the frame, i.e. x_real_positions gets called > and is most likely due to GTK windows bee-ing only partially mapped. >=20 > I think we can figure this out, when it becomes clear, which absolute > position `window-absolute-pixel-edges' should actually return. Race conditions are common when a window manager is involved. Another = reason to keep pixels private and not export them to Elisp. Jan D.. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 12:05:47 2013 Received: (at 5721) by debbugs.gnu.org; 29 Sep 2013 16:05:47 +0000 Received: from localhost ([127.0.0.1]:44973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQJVC-0001vG-BH for submit@debbugs.gnu.org; Sun, 29 Sep 2013 12:05:46 -0400 Received: from mail01.bdtv.se ([176.10.222.34]:33745) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1VQJVA-0001v6-4y for 5721@debbugs.gnu.org; Sun, 29 Sep 2013 12:05:44 -0400 Received: (qmail 1654 invoked by uid 89); 29 Sep 2013 16:05:43 -0000 Received: from h-46-59-42-57.na.cust.bahnhof.se (HELO coolsville.localdomain) (boel.djarv@bdtv.se@46.59.42.57) by mail01.bdtv.se with ESMTPA; 29 Sep 2013 16:05:43 -0000 Received: from [172.20.199.13] (unknown [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id D6C6F1A00FB; Sun, 29 Sep 2013 16:05:42 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates From: =?iso-8859-1?Q?Jan_Dj=E4rv?= In-Reply-To: <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> Date: Sun, 29 Sep 2013 18:05:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A35A160-E728-4617-A65E-D79EC75B88D2@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> To: Andreas Politz X-Mailer: Apple Mail (2.1510) X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 5721 Cc: martin rudalics , 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) Hello. 29 sep 2013 kl. 18:02 skrev Jan Dj=E4rv : > Hello. >=20 > 29 sep 2013 kl. 17:41 skrev Andreas Politz = : >=20 >> martin rudalics writes: >>=20 >>> I'm not sure whether we can correctly retrieve the decorations = always >>> and everywhere. >>=20 >> It seems to me, that x_real_positions (xfns.c) does the right thing >> independent of the WM, i.e. it searches the last parent before the = root >> Window, assumes that it is the outermost Window of the frame and >> computes the difference to the inner Emacs window (FRAME_X_WINDOW). >>=20 >=20 > This is known to be wrong. For example, if some Gtk+ version does = create separate X windows for menu bar and tool bar, the approach gives = the offset to the Emacs text area below the tool bar. >=20 > If Gtk+ does NOT use separate windows for the menu- and/or tool-bar, = but instead uses the FRAME_X_WINDOW, you get the coordinates to the = menu- and/or tool bar. Forgot to mention that the window manager window that the title bar is = drawn in does not need to be a parent of any Emacs X window. In that = case you can not get the size of the decorations at all. Jan D. >=20 >>=20 >> The patch works for me with GTK, with internal-border-width and >> full-screen set, with Xmonad as well as fluxbox. `border-width' in >> make-frame does not seem to make any difference, it's probably set = via a >> GTK style (?). Anyway the only problem I sometimes ran into is a = race >> condition, resulting in y_pixels_diff being to small. But this is = only >> temporarily until I move the frame, i.e. x_real_positions gets called >> and is most likely due to GTK windows bee-ing only partially mapped. >>=20 >> I think we can figure this out, when it becomes clear, which absolute >> position `window-absolute-pixel-edges' should actually return. >=20 > Race conditions are common when a window manager is involved. Another = reason to keep pixels private and not export them to Elisp. >=20 > Jan D.. >=20 From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 13:21:52 2013 Received: (at 5721) by debbugs.gnu.org; 29 Sep 2013 17:21:52 +0000 Received: from localhost ([127.0.0.1]:45008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQKgp-0003jZ-D2 for submit@debbugs.gnu.org; Sun, 29 Sep 2013 13:21:51 -0400 Received: from gateway-a.fh-trier.de ([143.93.54.181]:37021) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQKgk-0003jO-JV for 5721@debbugs.gnu.org; Sun, 29 Sep 2013 13:21:47 -0400 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier] Received: from luca (dslb-084-059-253-081.pools.arcor-ip.net [84.59.253.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-a.fh-trier.de (Postfix) with ESMTPSA id 5B24517608DD; Sun, 29 Sep 2013 19:21:30 +0200 (CEST) Received: from politza by luca with local (Exim 4.72) (envelope-from ) id 1VQKgT-0003Dq-Mo; Sun, 29 Sep 2013 19:21:29 +0200 From: Andreas Politz To: Jan =?utf-8?Q?Dj=C3=A4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> <4A35A160-E728-4617-A65E-D79EC75B88D2@swipnet.se> Date: Sun, 29 Sep 2013 19:21:29 +0200 In-Reply-To: <4A35A160-E728-4617-A65E-D79EC75B88D2@swipnet.se> ("Jan =?utf-8?Q?Dj=C3=A4rv=22's?= message of "Sun, 29 Sep 2013 18:05:43 +0200") Message-ID: <87eh87tug6.fsf@hochschule-trier.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 5721 Cc: martin rudalics , 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Jan Dj=C3=A4rv writes: >> This is known to be wrong. For example, if some Gtk+ version does >> create separate X windows [...] So, it depends on the toolkit and in some cases the tool-kit's version. > Forgot to mention that the window manager window that the title bar is > drawn in does not need to be a parent of any Emacs X window. In that > case you can not get the size of the decorations at all. > ,,does not need'' does not mean that any window manager does this. Care to give an example ?=20=20 Also the size of the decoration doesn't really matter, as long as we can figure out the difference between the absolute frame position and the start of the edit window. Or could it also be possible, that the frame's absolute position (left, top) does point to the coordinates of a window of which the inner Emacs window is not a child ? >>> [...] Anyway the only problem I sometimes ran into is a race >>> condition, resulting in y_pixels_diff being to small. But this is only >>> temporarily [...] >> Race conditions are common when a window manager is involved. >> Another reason to keep pixels private and not export them to Elisp. Just something that has to be dealt with. Either way the function exists and we can try to fix it or remove it. I don't see what purpose it serves in it's current state. The request came from the author of auto-complete, a package which displays completion candidates and their documentation with overlays and tool-tips at point. I'd like to see this move forward and, in the end, use undecorated frames instead. Without this function, this is impossible without external programs. BTW any other recent editor does this (e.g. http://cdn3.cybernetnews.com/wp-content/uploads/2008/06/notepad-5.png= ), so I doubt that it's 'impossible'. -ap P.S.: I tried the patch on a bare --with-x-toolkit=3Dno build and it seems to give the correct values. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 14:09:39 2013 Received: (at 5721) by debbugs.gnu.org; 29 Sep 2013 18:09:39 +0000 Received: from localhost ([127.0.0.1]:45055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQLR4-0004xT-2A for submit@debbugs.gnu.org; Sun, 29 Sep 2013 14:09:38 -0400 Received: from mail01.bdtv.se ([176.10.222.34]:34445) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1VQLQz-0004xF-Sh for 5721@debbugs.gnu.org; Sun, 29 Sep 2013 14:09:35 -0400 Received: (qmail 8985 invoked by uid 89); 29 Sep 2013 18:09:32 -0000 Received: from h-46-59-42-57.na.cust.bahnhof.se (HELO coolsville.localdomain) (boel.djarv@bdtv.se@46.59.42.57) by mail01.bdtv.se with ESMTPA; 29 Sep 2013 18:09:32 -0000 Received: from [172.20.199.13] (unknown [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id E57761A0271; Sun, 29 Sep 2013 18:09:31 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates From: =?iso-8859-1?Q?Jan_Dj=E4rv?= In-Reply-To: <87eh87tug6.fsf@hochschule-trier.de> Date: Sun, 29 Sep 2013 20:09:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1E552DE5-8FD1-45B9-A18B-B1532C6108CE@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> <4A35A160-E728-4617-A65E-D79EC75B88D2@swipnet.se> <87eh87tug6.fsf@hochschule-trier.de> To: Andreas Politz X-Mailer: Apple Mail (2.1510) X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 5721 Cc: martin rudalics , 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) Hello. 29 sep 2013 kl. 19:21 skrev Andreas Politz = : > Jan Dj=E4rv writes: >=20 >>> This is known to be wrong. For example, if some Gtk+ version does >>> create separate X windows [...] >=20 > So, it depends on the toolkit and in some cases the tool-kit's = version. >=20 >> Forgot to mention that the window manager window that the title bar = is >> drawn in does not need to be a parent of any Emacs X window. In that >> case you can not get the size of the decorations at all. >>=20 >=20 > ,,does not need'' does not mean that any window manager does this. = Care > to give an example ? =20 Some versions of Compiz and other composite managers. >=20 > Also the size of the decoration doesn't really matter, as long as we = can > figure out the difference between the absolute frame position and the > start of the edit window. Or could it also be possible, that the > frame's absolute position (left, top) does point to the coordinates of = a > window of which the inner Emacs window is not a child ? If "frame" includes the window decorations, yes. >=20 >=20 >>>> [...] Anyway the only problem I sometimes ran into is a race >>>> condition, resulting in y_pixels_diff being to small. But this is = only >>>> temporarily [...] >=20 >>> Race conditions are common when a window manager is involved. >>> Another reason to keep pixels private and not export them to Elisp. >=20 > The request came from the author of auto-complete, a package which > displays completion candidates and their documentation with overlays = and > tool-tips at point. I'd like to see this move forward and, in the = end, > use undecorated frames instead. Without this function, this is > impossible without external programs. BTW any other recent editor = does this > (e.g. = http://cdn3.cybernetnews.com/wp-content/uploads/2008/06/notepad-5.png), > so I doubt that it's 'impossible'. I doubt the applcation do it by calculating offsets of positions based = on where on the screen the top/left corner happens to be on the screen. = It is quite easy in a toolkit to=20 add a transient-for window and do some translate coordinates between = them. No need for absolute coordinates at all. That is all taken care = of by the toolkit that knows the ins and outs of the X windows involved, = and has access to private data the application has not. >=20 > -ap >=20 > P.S.: I tried the patch on a bare --with-x-toolkit=3Dno build and it = seems > to give the correct values. Of course, the whole thing with absolute pixel calculations was = developed with bare X in mind. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 14:47:03 2013 Received: (at 5721) by debbugs.gnu.org; 29 Sep 2013 18:47:03 +0000 Received: from localhost ([127.0.0.1]:45103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQM1G-0005sh-Ch for submit@debbugs.gnu.org; Sun, 29 Sep 2013 14:47:02 -0400 Received: from mout.gmx.net ([212.227.17.20]:63097) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQM1B-0005sC-6l for 5721@debbugs.gnu.org; Sun, 29 Sep 2013 14:46:58 -0400 Received: from [62.47.35.113] ([62.47.35.113]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MaIw0-1V6UmV30MC-00JqBP for <5721@debbugs.gnu.org>; Sun, 29 Sep 2013 20:46:55 +0200 Message-ID: <5248759A.9010604@gmx.at> Date: Sun, 29 Sep 2013 20:46:50 +0200 From: martin rudalics MIME-Version: 1.0 To: Andreas Politz Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> In-Reply-To: <87mwmvtz26.fsf@hochschule-trier.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:njVRuuRqYHmGUQ3ZHsEMdUHoUnCPF1I8JQ7+VSDkOl941Fo4gsf brI0jtZjekDIrPr/2fsWZhG8NY8fzDlp/dVlmk3aiIHff0Aw2YUVSzbe8kh/CIprjkLYxJ3 lr4anAB37VHX1+GDMt6TiNj8RLyrbbAVuzU3mWSFn1f51bIs6Pa6FeGI7mU+ZtXuXJMy2c/ uGeYJ2BeSqd90Gz+sqVZA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > The patch isn't perfect, as in I only tested it with GTK. Are you > talking about the frame parameter `border-width' or > `internal-border-width' ? I mean the outer border width as established by the window manager. > I think, as long as we can now the absolute > position of (the window at) C, this should probably make no difference, > since it shouldn't matter how much of the space of (C - A) is spent on > the border or a title (?). C - A might be the outer border width. But it might also include a left scroll- or toolbar IIUC. > The patch works for me with GTK, with internal-border-width This surprises me because I don't see where internal-border-width is handled in calc_absolute_offset. Is it because f->left_pos does already account for the internal border width? > and > full-screen set, with Xmonad as well as fluxbox. `border-width' in > make-frame does not seem to make any difference, it's probably set via a > GTK style (?). I think so. > Anyway the only problem I sometimes ran into is a race > condition, resulting in y_pixels_diff being to small. But this is only > temporarily until I move the frame, i.e. x_real_positions gets called > and is most likely due to GTK windows bee-ing only partially mapped. > > I think we can figure this out, when it becomes clear, which absolute > position `window-absolute-pixel-edges' should actually return. ISTR two problems from the last time I looked into this: You cannot always get C - A (or B - A) from the system and with fullscreen and maximized frames A is occasionally less than zero. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 14:47:17 2013 Received: (at 5721) by debbugs.gnu.org; 29 Sep 2013 18:47:17 +0000 Received: from localhost ([127.0.0.1]:45106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQM1V-0005t9-3l for submit@debbugs.gnu.org; Sun, 29 Sep 2013 14:47:17 -0400 Received: from mout.gmx.net ([212.227.15.19]:49604) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQM1T-0005t1-60 for 5721@debbugs.gnu.org; Sun, 29 Sep 2013 14:47:15 -0400 Received: from [62.47.35.113] ([62.47.35.113]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0M8qOm-1VY1WQ0Vye-00C9Rg for <5721@debbugs.gnu.org>; Sun, 29 Sep 2013 20:47:14 +0200 Message-ID: <524875AC.5020104@gmx.at> Date: Sun, 29 Sep 2013 20:47:08 +0200 From: martin rudalics MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> In-Reply-To: <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:dEGYZah0cCNrS515UN4QVd/isY8GFFC9+7b69zM9n9zdyCUSrLW fK6qCwKggYpf5TsTfqz5rZdNxD27PNWmKEj6sZIYwf6Q6mE0caNOkBiMKykxuVkXs+npWu9 LlD27y+rRuSzeuYqnH7DuWKYAqQS2ArxZUqWCNi74uIrfGllqRWo1Aubs1RW8F8Zwl8iXhG tbY6VQ2eXWHaAvoYGGKwA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, Andreas Politz X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > Race conditions are common when a window manager is involved. Another reason to keep pixels private and not export them to Elisp. This argument (1) applies to all values returned by window managers and (2) affects C code just as well as Lisp code. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 14:47:27 2013 Received: (at 5721) by debbugs.gnu.org; 29 Sep 2013 18:47:27 +0000 Received: from localhost ([127.0.0.1]:45109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQM1e-0005tV-Gc for submit@debbugs.gnu.org; Sun, 29 Sep 2013 14:47:27 -0400 Received: from mout.gmx.net ([212.227.15.15]:56617) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQM1b-0005tM-HM for 5721@debbugs.gnu.org; Sun, 29 Sep 2013 14:47:24 -0400 Received: from [62.47.35.113] ([62.47.35.113]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0LgvEY-1WEU4i29As-00oDt0 for <5721@debbugs.gnu.org>; Sun, 29 Sep 2013 20:47:22 +0200 Message-ID: <524875B5.9060402@gmx.at> Date: Sun, 29 Sep 2013 20:47:17 +0200 From: martin rudalics MIME-Version: 1.0 To: Andreas Politz Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> <4A35A160-E728-4617-A65E-D79EC75B88D2@swipnet.se> <87eh87tug6.fsf@hochschule-trier.de> In-Reply-To: <87eh87tug6.fsf@hochschule-trier.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:XdZN9ADgj0Oc8lhotigC2NSh3g9g3drsjUDOo6x9/MUQbarMXa1 nYiw9gprpyFMOAIsPX7sN6LXBQ8GHA/gPErKcU+m9VcnZ2VouD78zsXwHnQk8y/1dHL9Rck VBLxmoIaCX02mBiKinVB+EgK6bunntMj7R10mhpOf4lUgVkf8jiVBzlULQKzQ/E4cOXe/aI pSgrxXg924xhC9EzRqc1A== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, =?UTF-8?B?SmFuIERqw6Rydg==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > Also the size of the decoration doesn't really matter, as long as we can > figure out the difference between the absolute frame position and the > start of the edit window. But the decorations are part of this difference. They are between the absolute frame position and the position of the frame's root window. > P.S.: I tried the patch on a bare --with-x-toolkit=no build and it seems > to give the correct values. How to you establish that a value is "correct"? martin From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 16:10:13 2013 Received: (at 5721) by debbugs.gnu.org; 29 Sep 2013 20:10:14 +0000 Received: from localhost ([127.0.0.1]:45175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQNJl-0007ok-Hy for submit@debbugs.gnu.org; Sun, 29 Sep 2013 16:10:13 -0400 Received: from mail01.bdtv.se ([176.10.222.34]:34931) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1VQNJi-0007oZ-N3 for 5721@debbugs.gnu.org; Sun, 29 Sep 2013 16:10:11 -0400 Received: (qmail 15111 invoked by uid 89); 29 Sep 2013 20:10:08 -0000 Received: from h-46-59-42-57.na.cust.bahnhof.se (HELO coolsville.localdomain) (boel.djarv@bdtv.se@46.59.42.57) by mail01.bdtv.se with ESMTPA; 29 Sep 2013 20:10:08 -0000 Received: from [172.20.199.13] (unknown [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 3F2EB1A00FB; Sun, 29 Sep 2013 20:10:08 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates From: =?iso-8859-1?Q?Jan_Dj=E4rv?= In-Reply-To: <524875AC.5020104@gmx.at> Date: Sun, 29 Sep 2013 22:10:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> <524875AC.5020104@gmx.at> To: martin rudalics X-Mailer: Apple Mail (2.1510) X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, Andreas Politz X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) Hello. 29 sep 2013 kl. 20:47 skrev martin rudalics : > > Race conditions are common when a window manager is involved. = Another reason to keep pixels private and not export them to Elisp. >=20 > This argument (1) applies to all values returned by window managers I don't see how that follows. We are talking about sizes and positions = in pixels. States like fullscreen, iconifyed are not affected as I see = it. > and (2) affects C code just as well as Lisp code. C-functions that are defuns, sure, but I see that as Lisp code. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 16:26:14 2013 Received: (at 5721) by debbugs.gnu.org; 29 Sep 2013 20:26:14 +0000 Received: from localhost ([127.0.0.1]:45181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQNZG-0008BA-4E for submit@debbugs.gnu.org; Sun, 29 Sep 2013 16:26:14 -0400 Received: from gateway-a.fh-trier.de ([143.93.54.181]:53328) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQNZD-0008B1-G8 for 5721@debbugs.gnu.org; Sun, 29 Sep 2013 16:26:12 -0400 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier] Received: from luca (dslb-084-059-253-081.pools.arcor-ip.net [84.59.253.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-a.fh-trier.de (Postfix) with ESMTPSA id 19FB11759275; Sun, 29 Sep 2013 22:25:55 +0200 (CEST) Received: from politza by luca with local (Exim 4.72) (envelope-from ) id 1VQNYw-0002qK-D1; Sun, 29 Sep 2013 22:25:54 +0200 From: Andreas Politz To: martin rudalics Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <5248759A.9010604@gmx.at> Date: Sun, 29 Sep 2013 22:25:54 +0200 In-Reply-To: <5248759A.9010604@gmx.at> (martin rudalics's message of "Sun, 29 Sep 2013 20:46:50 +0200") Message-ID: <87y56fs7cd.fsf@hochschule-trier.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) I may be badly confused, but here is how I understand this. We have two Windows (which may be the same, depending on tool-kit) FRAME_X_WINDOW I and FRAME_OUTER_WINDOW O . Both display some widget and I is a child of O. The fn x_real_positions (usually) takes O and traverses the tree up to the last Window before the root window. +------ | Root window +---- | T : The WM TOP window | +---- | | X: Some other WM window, border, title, whatever | +------ | | O : FRAME_OUTER_WINDOW | +-------- | | I : FRAME_X_WINDOW Then it computes I - T as [xy]_pixels_diff and it doesn't matter what the WM displays in T or X or if these windows even exist. I suppose with GTK the Window I represents the innermost text widget, i.e the Emacs frame-root-window. That would explain, why [xy]_pixels_diff already seem to contain internal-border-width, the toolbar (left + top), menu-bar etc. >From this there are two questions: a) Does T = (frame->top_left, frame->top_pos) always hold, and b) what does I stand for (e.g. is the menu-bar included or not etc.) ? If a) is true and b) can be known, as well as the differences to the edit area (which seem to be zero for GTK), we are good. Maybe a different approach would be to receive X11 events for Window I and go from there ? martin rudalics writes: > How to you establish that a value is "correct"? I display a tool-tip at the position of window-absolute-pixel-edges and look whether it displays at the right place, while changing the variables (internal-border-width, etc.). -ap From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 03 13:25:29 2013 Received: (at 5721) by debbugs.gnu.org; 3 Oct 2013 17:25:29 +0000 Received: from localhost ([127.0.0.1]:52149 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VRmeW-0002Ht-65 for submit@debbugs.gnu.org; Thu, 03 Oct 2013 13:25:28 -0400 Received: from gateway-b.fh-trier.de ([143.93.54.182]:50571) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VRmeS-0002Hh-CS for 5721@debbugs.gnu.org; Thu, 03 Oct 2013 13:25:25 -0400 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier] Received: from luca (dslb-146-060-061-089.pools.arcor-ip.net [146.60.61.89]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-b.fh-trier.de (Postfix) with ESMTPSA id 2189C17B4B3; Thu, 3 Oct 2013 19:25:06 +0200 (CEST) Received: from politza by luca with local (Exim 4.72) (envelope-from ) id 1VRmeA-0007HL-1k; Thu, 03 Oct 2013 19:25:06 +0200 From: Andreas Politz To: Jan =?utf-8?Q?Dj=C3=A4rv?= Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> <524875AC.5020104@gmx.at> Date: Thu, 03 Oct 2013 19:25:06 +0200 In-Reply-To: ("Jan =?utf-8?Q?Dj=C3=A4rv=22's?= message of "Sun, 29 Sep 2013 22:10:08 +0200") Message-ID: <87ioxe8dxp.fsf@hochschule-trier.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 5721 Cc: martin rudalics , 5721@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain Hi, I made another patch, see below. I build it with GTK and X-tool-kit and tested it on Xmonad, fluxbox and compiz, also on Windows 7. In all cases `window-inside-absolute-pixel-edges' seems to report the correct x-y values, i.e. the absolute position of the beginning of the text area. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=window-absolute-pixel.diff === modified file 'src/window.c' *** src/window.c 2013-10-02 12:08:27 +0000 --- src/window.c 2013-10-03 17:06:53 +0000 *************** *** 940,945 **** --- 940,950 ---- { struct frame *f = XFRAME (w->frame); *add_y = f->top_pos; + #ifdef HAVE_X_WINDOWS + *add_y += FRAME_X_OUTPUT (f)->y_pixels_outer_diff; + #elif defined (WINDOWSNT) + *add_y += f->y_pixels_diff; + #endif #ifdef FRAME_MENUBAR_HEIGHT *add_y += FRAME_MENUBAR_HEIGHT (f); #endif *************** *** 951,957 **** --- 956,968 ---- #ifdef FRAME_NS_TITLEBAR_HEIGHT *add_y += FRAME_NS_TITLEBAR_HEIGHT (f); #endif + *add_x = f->left_pos; + #ifdef HAVE_X_WINDOWS + *add_x += FRAME_X_OUTPUT (f)->x_pixels_outer_diff; + #elif defined (WINDOWSNT) + *add_x += f->x_pixels_diff; + #endif #ifdef FRAME_TOOLBAR_LEFT_WIDTH *add_x += FRAME_TOOLBAR_LEFT_WIDTH (f); #endif --=-=-= Content-Type: text/plain -ap --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 03 16:25:42 2013 Received: (at 5721) by debbugs.gnu.org; 3 Oct 2013 20:25:42 +0000 Received: from localhost ([127.0.0.1]:52346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VRpSv-0006SM-K0 for submit@debbugs.gnu.org; Thu, 03 Oct 2013 16:25:42 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:64162) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VRpSq-0006S9-TO for 5721@debbugs.gnu.org; Thu, 03 Oct 2013 16:25:38 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MU4002000G01R00@a-mtaout21.012.net.il> for 5721@debbugs.gnu.org; Thu, 03 Oct 2013 23:25:35 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MU4001WA0QMRQB0@a-mtaout21.012.net.il>; Thu, 03 Oct 2013 23:25:34 +0300 (IDT) Date: Thu, 03 Oct 2013 23:25:20 +0300 From: Eli Zaretskii Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-reply-to: <87ioxe8dxp.fsf@hochschule-trier.de> X-012-Sender: halo1@inter.net.il To: Andreas Politz Message-id: <83hacycdan.fsf@gnu.org> References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> <524875AC.5020104@gmx.at> <87ioxe8dxp.fsf@hochschule-trier.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, jan.h.d@swipnet.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Andreas Politz > Date: Thu, 03 Oct 2013 19:25:06 +0200 > Cc: 5721@debbugs.gnu.org > > I made another patch, see below. I build it with GTK and X-tool-kit and > tested it on Xmonad, fluxbox and compiz, also on Windows 7. In all > cases `window-inside-absolute-pixel-edges' seems to report the correct > x-y values, i.e. the absolute position of the beginning of the text > area. Thanks. The code conditioned by WINDOWSNT should instead be conditioned by NTGUI, since the same code should run for Cygwin built --with-w32. Also, I wonder why you aren't testing the frame type here -- this code should DTRT for TTYs as well, right? Or is it certain that this code will never run except in a GUI session? From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 03 17:09:54 2013 Received: (at 5721) by debbugs.gnu.org; 3 Oct 2013 21:09:54 +0000 Received: from localhost ([127.0.0.1]:52454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VRq9i-0007bB-6d for submit@debbugs.gnu.org; Thu, 03 Oct 2013 17:09:54 -0400 Received: from gateway-a.fh-trier.de ([143.93.54.181]:60406) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VRq9e-0007au-VI for 5721@debbugs.gnu.org; Thu, 03 Oct 2013 17:09:51 -0400 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier] Received: from luca (dslb-146-060-061-089.pools.arcor-ip.net [146.60.61.89]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-a.fh-trier.de (Postfix) with ESMTPSA id 8D3E8175451C; Thu, 3 Oct 2013 23:09:34 +0200 (CEST) Received: from politza by luca with local (Exim 4.72) (envelope-from ) id 1VRq9N-0006a0-Rc; Thu, 03 Oct 2013 23:09:33 +0200 From: Andreas Politz To: Eli Zaretskii Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> <524875AC.5020104@gmx.at> <87ioxe8dxp.fsf@hochschule-trier.de> <83hacycdan.fsf@gnu.org> Date: Thu, 03 Oct 2013 23:09:33 +0200 In-Reply-To: <83hacycdan.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 03 Oct 2013 23:25:20 +0300") Message-ID: <87eh8283jm.fsf@hochschule-trier.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, jan.h.d@swipnet.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Eli Zaretskii writes: > The code conditioned by WINDOWSNT should instead be conditioned by > NTGUI, since the same code should run for Cygwin built --with-w32. Ok. > Also, I wonder why you aren't testing the frame type here -- this code > should DTRT for TTYs as well, right? Or is it certain that this code > will never run except in a GUI session? I don't know if this function is able to return something meaningful in a terminal. At least it does not to do so at the moment (in the current, unpatched bzr branch): emacs -nw -Q (window-inside-absolute-pixel-edges) => (32752 20946769 32850 20946817) Should these functions (`window-absolute-pixel-edges' and `window-inside-absolute-pixel-edges') return nil in a terminal ? -ap From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 04 02:48:11 2013 Received: (at 5721) by debbugs.gnu.org; 4 Oct 2013 06:48:11 +0000 Received: from localhost ([127.0.0.1]:53027 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VRzBK-0005VX-Ej for submit@debbugs.gnu.org; Fri, 04 Oct 2013 02:48:10 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:46029) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VRzBF-0005VL-Vp for 5721@debbugs.gnu.org; Fri, 04 Oct 2013 02:48:07 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MU400B00TFBEI00@a-mtaout22.012.net.il> for 5721@debbugs.gnu.org; Fri, 04 Oct 2013 09:47:50 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MU400BNUTJQ4W90@a-mtaout22.012.net.il>; Fri, 04 Oct 2013 09:47:50 +0300 (IDT) Date: Fri, 04 Oct 2013 09:47:38 +0300 From: Eli Zaretskii Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-reply-to: <87eh8283jm.fsf@hochschule-trier.de> X-012-Sender: halo1@inter.net.il To: Andreas Politz Message-id: <83bo35cz1x.fsf@gnu.org> References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> <524875AC.5020104@gmx.at> <87ioxe8dxp.fsf@hochschule-trier.de> <83hacycdan.fsf@gnu.org> <87eh8283jm.fsf@hochschule-trier.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, jan.h.d@swipnet.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Andreas Politz > Cc: jan.h.d@swipnet.se, 5721@debbugs.gnu.org > Date: Thu, 03 Oct 2013 23:09:33 +0200 > > > Also, I wonder why you aren't testing the frame type here -- this code > > should DTRT for TTYs as well, right? Or is it certain that this code > > will never run except in a GUI session? > > I don't know if this function is able to return something meaningful in > a terminal. At least it does not to do so at the moment (in the > current, unpatched bzr branch): > > emacs -nw -Q > > (window-inside-absolute-pixel-edges) > > => (32752 20946769 32850 20946817) > > Should these functions (`window-absolute-pixel-edges' and > `window-inside-absolute-pixel-edges') return nil in a terminal ? I see no reason to do that. We do support pixel coordinates on a text terminal, counting each column and row as one pixel. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 04 04:28:43 2013 Received: (at 5721) by debbugs.gnu.org; 4 Oct 2013 08:28:43 +0000 Received: from localhost ([127.0.0.1]:53146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VS0kc-0007nP-FC for submit@debbugs.gnu.org; Fri, 04 Oct 2013 04:28:42 -0400 Received: from gateway-b.fh-trier.de ([143.93.54.182]:52096) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VS0kZ-0007nG-Pn for 5721@debbugs.gnu.org; Fri, 04 Oct 2013 04:28:40 -0400 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier] Received: from luca (dslb-146-060-061-089.pools.arcor-ip.net [146.60.61.89]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-b.fh-trier.de (Postfix) with ESMTPSA id 7C9DA17B4CB; Fri, 4 Oct 2013 10:28:18 +0200 (CEST) Received: from politza by luca with local (Exim 4.72) (envelope-from ) id 1VS0kD-0002mG-MZ; Fri, 04 Oct 2013 10:28:17 +0200 From: Andreas Politz To: Eli Zaretskii Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> <524875AC.5020104@gmx.at> <87ioxe8dxp.fsf@hochschule-trier.de> <83hacycdan.fsf@gnu.org> <87eh8283jm.fsf@hochschule-trier.de> <83bo35cz1x.fsf@gnu.org> Date: Fri, 04 Oct 2013 10:28:17 +0200 In-Reply-To: <83bo35cz1x.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 04 Oct 2013 09:47:38 +0300") Message-ID: <874n8xh23i.fsf@hochschule-trier.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, jan.h.d@swipnet.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> Should these functions (`window-absolute-pixel-edges' and >> `window-inside-absolute-pixel-edges') return nil in a terminal ? > > I see no reason to do that. We do support pixel coordinates on a text > terminal, counting each column and row as one pixel. Then they should probably return the same values as the non-absolute counterparts. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=window-absolute-pixel-v2.diff === modified file 'src/window.c' *** src/window.c 2013-10-02 12:08:27 +0000 --- src/window.c 2013-10-04 08:05:28 +0000 *************** *** 935,945 **** WINDOW_RIGHT_EDGE_X (w), WINDOW_BOTTOM_EDGE_Y (w)); } static void ! calc_absolute_offset (struct window *w, int *add_x, int *add_y) { ! struct frame *f = XFRAME (w->frame); *add_y = f->top_pos; #ifdef FRAME_MENUBAR_HEIGHT *add_y += FRAME_MENUBAR_HEIGHT (f); #endif --- 935,952 ---- WINDOW_RIGHT_EDGE_X (w), WINDOW_BOTTOM_EDGE_Y (w)); } + #ifdef HAVE_WINDOW_SYSTEM static void ! calc_absolute_offset (struct frame *f, int *add_x, int *add_y) { ! eassert (FRAME_WINDOW_P (f)); ! *add_y = f->top_pos; + #ifdef HAVE_X_WINDOWS + *add_y += FRAME_X_OUTPUT (f)->y_pixels_outer_diff; + #elif defined (HAVE_NTGUI) + *add_y += f->y_pixels_diff; + #endif #ifdef FRAME_MENUBAR_HEIGHT *add_y += FRAME_MENUBAR_HEIGHT (f); #endif *************** *** 951,961 **** --- 958,975 ---- #ifdef FRAME_NS_TITLEBAR_HEIGHT *add_y += FRAME_NS_TITLEBAR_HEIGHT (f); #endif + *add_x = f->left_pos; + #ifdef HAVE_X_WINDOWS + *add_x += FRAME_X_OUTPUT (f)->x_pixels_outer_diff; + #elif defined (HAVE_NTGUI) + *add_x += f->x_pixels_diff; + #endif #ifdef FRAME_TOOLBAR_LEFT_WIDTH *add_x += FRAME_TOOLBAR_LEFT_WIDTH (f); #endif } + #endif /* HAVE_WINDOW_SYSTEM */ DEFUN ("window-absolute-pixel-edges", Fwindow_absolute_pixel_edges, Swindow_absolute_pixel_edges, 0, 1, 0, *************** *** 972,987 **** of just the text area, use `window-inside-absolute-pixel-edges'. */) (Lisp_Object window) { register struct window *w = decode_valid_window (window); int add_x, add_y; ! calc_absolute_offset (w, &add_x, &add_y); return list4i (WINDOW_LEFT_EDGE_X (w) + add_x, WINDOW_TOP_EDGE_Y (w) + add_y, WINDOW_RIGHT_EDGE_X (w) + add_x, WINDOW_BOTTOM_EDGE_Y (w) + add_y); } DEFUN ("window-inside-edges", Fwindow_inside_edges, Swindow_inside_edges, 0, 1, 0, doc: /* Return a list of the edge coordinates of WINDOW. --- 986,1009 ---- of just the text area, use `window-inside-absolute-pixel-edges'. */) (Lisp_Object window) { + #if HAVE_WINDOW_SYSTEM register struct window *w = decode_valid_window (window); + struct frame *f = XFRAME (w->frame); int add_x, add_y; ! if (FRAME_WINDOW_P (f)) ! { ! calc_absolute_offset (f, &add_x, &add_y); return list4i (WINDOW_LEFT_EDGE_X (w) + add_x, WINDOW_TOP_EDGE_Y (w) + add_y, WINDOW_RIGHT_EDGE_X (w) + add_x, WINDOW_BOTTOM_EDGE_Y (w) + add_y); } + else + #endif + return Fwindow_pixel_edges (window); + } DEFUN ("window-inside-edges", Fwindow_inside_edges, Swindow_inside_edges, 0, 1, 0, doc: /* Return a list of the edge coordinates of WINDOW. *************** *** 1053,1062 **** display margins, fringes, header line, and/or mode line. */) (Lisp_Object window) { ! register struct window *w = decode_live_window (window); int add_x, add_y; ! calc_absolute_offset (w, &add_x, &add_y); return list4i ((WINDOW_BOX_LEFT_EDGE_X (w) + WINDOW_LEFT_MARGIN_WIDTH (w) --- 1075,1088 ---- display margins, fringes, header line, and/or mode line. */) (Lisp_Object window) { ! #if HAVE_WINDOW_SYSTEM ! register struct window *w = decode_valid_window (window); ! struct frame *f = XFRAME (w->frame); int add_x, add_y; ! if (FRAME_WINDOW_P (f)) ! { ! calc_absolute_offset (f, &add_x, &add_y); return list4i ((WINDOW_BOX_LEFT_EDGE_X (w) + WINDOW_LEFT_MARGIN_WIDTH (w) *************** *** 1069,1074 **** --- 1095,1104 ---- (WINDOW_BOTTOM_EDGE_Y (w) - WINDOW_MODE_LINE_HEIGHT (w) + add_y)); } + else + #endif + return Fwindow_inside_pixel_edges (window); + } /* Test if the character at column X, row Y is within window W. If it is not, return ON_NOTHING; --=-=-= Content-Type: text/plain -ap --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 04 04:55:45 2013 Received: (at 5721) by debbugs.gnu.org; 4 Oct 2013 08:55:45 +0000 Received: from localhost ([127.0.0.1]:53172 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VS1Am-0008RD-2S for submit@debbugs.gnu.org; Fri, 04 Oct 2013 04:55:44 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:40991) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VS1Af-0008R1-UK for 5721@debbugs.gnu.org; Fri, 04 Oct 2013 04:55:39 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MU400C00ZF2GX00@a-mtaout22.012.net.il> for 5721@debbugs.gnu.org; Fri, 04 Oct 2013 11:55:36 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MU400C6IZGNAG50@a-mtaout22.012.net.il>; Fri, 04 Oct 2013 11:55:36 +0300 (IDT) Date: Fri, 04 Oct 2013 11:55:23 +0300 From: Eli Zaretskii Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates In-reply-to: <874n8xh23i.fsf@hochschule-trier.de> X-012-Sender: halo1@inter.net.il To: Andreas Politz Message-id: <837gdtct50.fsf@gnu.org> References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> <524875AC.5020104@gmx.at> <87ioxe8dxp.fsf@hochschule-trier.de> <83hacycdan.fsf@gnu.org> <87eh8283jm.fsf@hochschule-trier.de> <83bo35cz1x.fsf@gnu.org> <874n8xh23i.fsf@hochschule-trier.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, jan.h.d@swipnet.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Andreas Politz > Cc: jan.h.d@swipnet.se, 5721@debbugs.gnu.org > Date: Fri, 04 Oct 2013 10:28:17 +0200 > > >> Should these functions (`window-absolute-pixel-edges' and > >> `window-inside-absolute-pixel-edges') return nil in a terminal ? > > > > I see no reason to do that. We do support pixel coordinates on a text > > terminal, counting each column and row as one pixel. > > Then they should probably return the same values as the non-absolute > counterparts. Yes, this sounds correct, thanks. One more nit, about these fragments: > + #ifdef HAVE_WINDOW_SYSTEM > static void > ! calc_absolute_offset (struct frame *f, int *add_x, int *add_y) > { > ! eassert (FRAME_WINDOW_P (f)); > ! > *add_y = f->top_pos; > + #ifdef HAVE_X_WINDOWS > + *add_y += FRAME_X_OUTPUT (f)->y_pixels_outer_diff; > + #elif defined (HAVE_NTGUI) > + *add_y += f->y_pixels_diff; > + #endif > #ifdef FRAME_MENUBAR_HEIGHT > *add_y += FRAME_MENUBAR_HEIGHT (f); > #endif > *************** > *** 951,961 **** > --- 958,975 ---- > #ifdef FRAME_NS_TITLEBAR_HEIGHT > *add_y += FRAME_NS_TITLEBAR_HEIGHT (f); > #endif > + > *add_x = f->left_pos; > + #ifdef HAVE_X_WINDOWS > + *add_x += FRAME_X_OUTPUT (f)->x_pixels_outer_diff; > + #elif defined (HAVE_NTGUI) > + *add_x += f->x_pixels_diff; > + #endif > #ifdef FRAME_TOOLBAR_LEFT_WIDTH > *add_x += FRAME_TOOLBAR_LEFT_WIDTH (f); > #endif > } > + #endif /* HAVE_WINDOW_SYSTEM */ For the possibility that the same Emacs session can support several different types of frames, it is better to check the frame type at run time, not just rely on compile-time conditional. Like this: #ifdef HAVE_X_WINDOWS if (FRAME_X_P (f)) *add_y += FRAME_X_OUTPUT (f)->y_pixels_outer_diff; else #elif defined (HAVE_NTGUI) if (FRAME_W32_P (f)) *add_y += f->y_pixels_diff; #endif etc., you get the idea. The above will work if the same session can have both X and w32 frames, something that is currently impossible (AFAIK), but is not unimaginable in principle. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 04 06:34:18 2013 Received: (at 5721) by debbugs.gnu.org; 4 Oct 2013 10:34:18 +0000 Received: from localhost ([127.0.0.1]:53270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VS2i8-0003SV-IH for submit@debbugs.gnu.org; Fri, 04 Oct 2013 06:34:17 -0400 Received: from gateway-a.fh-trier.de ([143.93.54.181]:43569) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VS2i6-0003SI-8l for 5721@debbugs.gnu.org; Fri, 04 Oct 2013 06:34:15 -0400 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier] Received: from luca (dslb-146-060-061-089.pools.arcor-ip.net [146.60.61.89]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-a.fh-trier.de (Postfix) with ESMTPSA id E507F1760D77; Fri, 4 Oct 2013 12:33:57 +0200 (CEST) Received: from politza by luca with local (Exim 4.72) (envelope-from ) id 1VS2hp-0000J0-8D; Fri, 04 Oct 2013 12:33:57 +0200 From: Andreas Politz To: Eli Zaretskii Subject: Re: bug#5721: Feature request: Function that returns absolute coordinates References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> <524875AC.5020104@gmx.at> <87ioxe8dxp.fsf@hochschule-trier.de> <83hacycdan.fsf@gnu.org> <87eh8283jm.fsf@hochschule-trier.de> <83bo35cz1x.fsf@gnu.org> <874n8xh23i.fsf@hochschule-trier.de> <837gdtct50.fsf@gnu.org> Date: Fri, 04 Oct 2013 12:33:57 +0200 In-Reply-To: <837gdtct50.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 04 Oct 2013 11:55:23 +0300") Message-ID: <87txgxfhpm.fsf@hochschule-trier.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 5721 Cc: 5721@debbugs.gnu.org, jan.h.d@swipnet.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain Eli Zaretskii writes: > One more nit, about these fragments: [...] it is better to check the > frame type at run time, [...] > #ifdef HAVE_X_WINDOWS > if (FRAME_X_P (f)) > *add_y += FRAME_X_OUTPUT (f)->y_pixels_outer_diff; > else > #elif defined (HAVE_NTGUI) > if (FRAME_W32_P (f)) > *add_y += f->y_pixels_diff; > #endif > > etc., you get the idea. I don't think that quite does what you have in mind, but I get it. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=window-absolute-pixel-v3.diff === modified file 'src/window.c' *** src/window.c 2013-10-02 12:08:27 +0000 --- src/window.c 2013-10-04 10:13:26 +0000 *************** *** 935,945 **** --- 935,974 ---- WINDOW_RIGHT_EDGE_X (w), WINDOW_BOTTOM_EDGE_Y (w)); } + #ifdef HAVE_WINDOW_SYSTEM static void calc_absolute_offset (struct window *w, int *add_x, int *add_y) { struct frame *f = XFRAME (w->frame); + + if (! FRAME_WINDOW_P (f)) + { + *add_x = *add_y = 0; + return; + } *add_y = f->top_pos; + *add_x = f->left_pos; + switch (f->output_method) + { + #ifdef HAVE_X_WINDOWS + case output_x_window: + *add_y += FRAME_X_OUTPUT (f)->y_pixels_outer_diff; + *add_x += FRAME_X_OUTPUT (f)->x_pixels_outer_diff; + break; + #endif + #ifdef HAVE_NTGUI + case output_w32: + *add_y += f->y_pixels_diff; + *add_x += f->x_pixels_diff; + break; + #endif + #ifdef HAVE_NS + case output_ns: + /* FIXME: Add proper offsets. */ + break; + #endif + } + #ifdef FRAME_MENUBAR_HEIGHT *add_y += FRAME_MENUBAR_HEIGHT (f); #endif *************** *** 951,961 **** #ifdef FRAME_NS_TITLEBAR_HEIGHT *add_y += FRAME_NS_TITLEBAR_HEIGHT (f); #endif ! *add_x = f->left_pos; #ifdef FRAME_TOOLBAR_LEFT_WIDTH *add_x += FRAME_TOOLBAR_LEFT_WIDTH (f); #endif } DEFUN ("window-absolute-pixel-edges", Fwindow_absolute_pixel_edges, Swindow_absolute_pixel_edges, 0, 1, 0, --- 980,991 ---- #ifdef FRAME_NS_TITLEBAR_HEIGHT *add_y += FRAME_NS_TITLEBAR_HEIGHT (f); #endif ! #ifdef FRAME_TOOLBAR_LEFT_WIDTH *add_x += FRAME_TOOLBAR_LEFT_WIDTH (f); #endif } + #endif /* HAVE_WINDOW_SYSTEM */ DEFUN ("window-absolute-pixel-edges", Fwindow_absolute_pixel_edges, Swindow_absolute_pixel_edges, 0, 1, 0, *************** *** 975,982 **** register struct window *w = decode_valid_window (window); int add_x, add_y; calc_absolute_offset (w, &add_x, &add_y); ! return list4i (WINDOW_LEFT_EDGE_X (w) + add_x, WINDOW_TOP_EDGE_Y (w) + add_y, WINDOW_RIGHT_EDGE_X (w) + add_x, --- 1005,1015 ---- register struct window *w = decode_valid_window (window); int add_x, add_y; + #ifdef HAVE_WINDOW_SYSTEM calc_absolute_offset (w, &add_x, &add_y); ! #else ! add_x = add_y = 0; ! #endif return list4i (WINDOW_LEFT_EDGE_X (w) + add_x, WINDOW_TOP_EDGE_Y (w) + add_y, WINDOW_RIGHT_EDGE_X (w) + add_x, *************** *** 1056,1063 **** register struct window *w = decode_live_window (window); int add_x, add_y; calc_absolute_offset (w, &add_x, &add_y); ! return list4i ((WINDOW_BOX_LEFT_EDGE_X (w) + WINDOW_LEFT_MARGIN_WIDTH (w) + WINDOW_LEFT_FRINGE_WIDTH (w) + add_x), --- 1089,1099 ---- register struct window *w = decode_live_window (window); int add_x, add_y; + #ifdef HAVE_WINDOW_SYSTEM calc_absolute_offset (w, &add_x, &add_y); ! #else ! add_x = add_y = 0; ! #endif return list4i ((WINDOW_BOX_LEFT_EDGE_X (w) + WINDOW_LEFT_MARGIN_WIDTH (w) + WINDOW_LEFT_FRINGE_WIDTH (w) + add_x), --=-=-= Content-Type: text/plain -ap --=-=-=-- From unknown Wed Jun 25 09:13:09 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 01 Nov 2013 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator