GNU bug report logs -
#5721
Feature request: Function that returns absolute coordinates
Previous Next
Reported by: irieshinsuke <at> yahoo.co.jp
Date: Mon, 15 Mar 2010 14:34:02 UTC
Severity: wishlist
Done: Jan Djärv <jan.h.d <at> swipnet.se>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5721 in the body.
You can then email your comments to 5721 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Mon, 15 Mar 2010 14:34:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
irieshinsuke <at> yahoo.co.jp:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 15 Mar 2010 14:34:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Severity set to 'wishlist' from 'normal'
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Fri, 19 Mar 2010 03:00:04 GMT)
Full text and
rfc822 format available.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Tue, 30 Mar 2010 17:51:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 5721 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Mon, 31 May 2010 10:29:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 5721 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Tue, 01 Jun 2010 01:17:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 31 May 2010 19:28:07 +0900, IRIE Shinsuke <irieshinsuke <at> yahoo.co.jp> 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 <at> math.s.chiba-u.ac.jp
Reply sent
to
Jan Djärv <jan.h.d <at> swipnet.se>:
You have taken responsibility.
(Thu, 01 Jul 2010 12:38:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
irieshinsuke <at> yahoo.co.jp:
bug acknowledged by developer.
(Thu, 01 Jul 2010 12:38:03 GMT)
Full text and
rfc822 format available.
Message #21 received at 5721-done <at> debbugs.gnu.org (full text, mbox):
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.
Message #22 received at 5721-done <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 01 Jul 2010 16:54:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 5721 <at> debbugs.gnu.org (full text, mbox):
Apparently this does not get delivered via Reply, since the address got changed
to 5721-done <at> debbugs.gnu.org instead of 5721 <at> debbugs.gnu.org. So trying again,
after correcting the address.
> From: Drew Adams [mailto:drew.adams <at> oracle.com]
> Sent: Thursday, July 01, 2010 6:07 AM
> To: 'Jan Djärv'; 'IRIE Shinsuke'
> Cc: '5721-done <at> debbugs.gnu.org'
> Subject: RE: bug#5721: Feature request: Function that
> returnsabsolute coordinates
>
> > 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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 01 Jul 2010 17:21:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 5721 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 01 Jul 2010 17:30:03 GMT)
Full text and
rfc822 format available.
Message #31 received at 5721 <at> debbugs.gnu.org (full text, mbox):
> >> 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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 01 Jul 2010 17:51:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 5721 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 01 Jul 2010 18:15:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 5721 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 01 Jul 2010 18:27:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 5721 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 01 Jul 2010 18:55:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 5721 <at> debbugs.gnu.org (full text, mbox):
> > 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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 01 Jul 2010 20:09:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 5721 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jul 1, 2010 at 20:26, Jan Djärv <jan.h.d <at> swipnet.se> 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. 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).
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
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 01 Jul 2010 22:06:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 5721 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jul 1, 2010 at 8:26 PM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>
> 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).
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 wise.
> If you can't implement it, file a new w32-specific bug.
No. Please don't!
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 02 Jul 2010 00:34:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>> 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\
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 02 Jul 2010 02:11:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 01 Jul 2010 14:37:22 +0200, Jan Djärv <jan.h.d <at> swipnet.se> 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 <mituharu <at> math.s.chiba-u.ac.jp> said:
> I'd rather suggest introducing some conversion functions between
> relative and absolute coordinate systems. Newer versions of Mac OS
> X provides "Resolution Independence" that allows users to specify a
> scale factor:
> http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/HiDPIOverview/HiDPIConcepts/HiDPIConcepts.html
> With the scale factor, 1 pixel in the relative coordinate system no
> longer always correspond to 1 pixel in the absolute one. Thus one
> cannot determine the corresponding absolute coordinates only from
> `inside-left' and `inside-top'.
(Maybe "pixel" above should be "unit".)
One can argue that the new API can return enough information to deal
with the scale factor by computing width and height in both relative
and absolute coordinate systems. But I guess many programmers just
tends to add some offsets for the conversion between these coordinate
systems. This might cause rewrite of elisp programs when GTK+
supports resolution independence in future.
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 02 Jul 2010 07:07:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 5721 <at> debbugs.gnu.org (full text, mbox):
YAMAMOTO Mitsuharu skrev 2010-07-02 04.10:
> What do you think about the following point?
>
>>>>>> On Tue, 01 Jun 2010 10:16:08 +0900, YAMAMOTO Mitsuharu<mituharu <at> math.s.chiba-u.ac.jp> said:
>
>> I'd rather suggest introducing some conversion functions between
>> relative and absolute coordinate systems. Newer versions of Mac OS
>> X provides "Resolution Independence" that allows users to specify a
>> scale factor:
>
>> http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/HiDPIOverview/HiDPIConcepts/HiDPIConcepts.html
>
>> With the scale factor, 1 pixel in the relative coordinate system no
>> longer always correspond to 1 pixel in the absolute one. Thus one
>> cannot determine the corresponding absolute coordinates only from
>> `inside-left' and `inside-top'.
>
> (Maybe "pixel" above should be "unit".)
>
> One can argue that the new API can return enough information to deal
> with the scale factor by computing width and height in both relative
> and absolute coordinate systems. But I guess many programmers just
> tends to add some offsets for the conversion between these coordinate
> systems. This might cause rewrite of elisp programs when GTK+
> supports resolution independence in future.
One could argue that we are always dealing with scaled pixels, and absolute in
this context means "absolute scaled" instead of "absolute unscaled". Can't we
always use scaled coordinates? When do we need to handle unscsaled?
The new functions use tool bar and title bar height as well as frame top and
left. Are these scaled or unscaled pixels? Shouldn't the nextstep specific
code just expose scaled pixels to the generic code and do the conversion when
needed? I know too little about which API functions that use scaled and which
use unscaled.
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 02 Jul 2010 09:16:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 02 Jul 2010 09:06:49 +0200, Jan Djärv <jan.h.d <at> swipnet.se> said:
> One could argue that we are always dealing with scaled pixels, and
> absolute in this context means "absolute scaled" instead of
> "absolute unscaled". Can't we always use scaled coordinates? When
> do we need to handle unscsaled?
I think major motivation to use the absolute coordinate system is to
specify the frame location (OP's case), or to pass it to external
programs (the SCIM case). "Absolute unscaled" one is more suitable
for such uses.
> The new functions use tool bar and title bar height as well as frame
> top and left. Are these scaled or unscaled pixels? Shouldn't the
> nextstep specific code just expose scaled pixels to the generic code
> and do the conversion when needed? I know too little about which
> API functions that use scaled and which use unscaled.
I've never cared about the tool bar and title bar height in the Mac
port because its explicit computation is unnecessary in Cocoa:
conversions between multiple coordinate systems (for views, windows,
and the screen) are provided as NSView/NSWindow methods. Sometimes
simple translation by offsets is not sufficient for these conversions:
it may involve flipping or scaling.
http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/HiDPIOverview/HiDPISupport/HiDPISupport.html
Using them, we could minimize the code change even if we changed the
position/scale of the view for Emacs frame relative to the enclosing
window.
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Wed, 14 Jul 2010 15:23:01 GMT)
Full text and
rfc822 format available.
Message #64 received at 5721 <at> debbugs.gnu.org (full text, mbox):
YAMAMOTO Mitsuharu skrev 2010-07-02 11.15:
>>>>>> On Fri, 02 Jul 2010 09:06:49 +0200, Jan Djärv<jan.h.d <at> swipnet.se> said:
>
>> One could argue that we are always dealing with scaled pixels, and
>> absolute in this context means "absolute scaled" instead of
>> "absolute unscaled". Can't we always use scaled coordinates? When
>> do we need to handle unscsaled?
>
> I think major motivation to use the absolute coordinate system is to
> specify the frame location (OP's case), or to pass it to external
> programs (the SCIM case). "Absolute unscaled" one is more suitable
> for such uses.
>
I would imagine that for frame positioning, absolute scaled would be the
default, as top and left frame parameters should also be absolute scaled.
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.
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 00:18:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 14 Jul 2010 17:22:27 +0200, Jan Djärv <jan.h.d <at> swipnet.se> 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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 06:08:01 GMT)
Full text and
rfc822 format available.
Message #70 received at 5721 <at> debbugs.gnu.org (full text, mbox):
YAMAMOTO Mitsuharu skrev 2010-07-15 02.17:
>>>>>> On Wed, 14 Jul 2010 17:22:27 +0200, Jan Djärv<jan.h.d <at> swipnet.se> 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).
As I said below, special functions to do that based on unscaled coordinates
would be needed. But for the default scaled should be used. Placing tooltips
for example is much more common than placing frames. Doing so based on scaled
coordinates is no problem. 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.
>
> 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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 06:50:03 GMT)
Full text and
rfc822 format available.
Message #73 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 15 Jul 2010 08:07:26 +0200, Jan Djärv <jan.h.d <at> swipnet.se> 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.
>>
>> 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 += f->left_pos +
FRAME_OUTER_TO_INNER_DIFF_X (f)'.
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 07:50:04 GMT)
Full text and
rfc822 format available.
Message #76 received at 5721 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 07:59:04 GMT)
Full text and
rfc822 format available.
Message #79 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 15 Jul 2010 09:50:05 +0200, Jan Djärv <jan.h.d <at> swipnet.se> 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.
>>
>>> 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.
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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 08:07:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 5721 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 08:19:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 15 Jul 2010 10:06:22 +0200, Jan Djärv <jan.h.d <at> swipnet.se> 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.
>> 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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 08:36:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 5721 <at> debbugs.gnu.org (full text, mbox):
YAMAMOTO Mitsuharu skrev 2010-07-15 10.18:
>>>>>> On Thu, 15 Jul 2010 10:06:22 +0200, Jan Djärv<jan.h.d <at> swipnet.se> 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, font
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 care.
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 08:45:03 GMT)
Full text and
rfc822 format available.
Message #91 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 15 Jul 2010 10:35:47 +0200, Jan Djärv <jan.h.d <at> swipnet.se> 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 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)?
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 09:00:04 GMT)
Full text and
rfc822 format available.
Message #94 received at 5721 <at> debbugs.gnu.org (full text, mbox):
YAMAMOTO Mitsuharu skrev 2010-07-15 10.44:
>>>>>> On Thu, 15 Jul 2010 10:35:47 +0200, Jan Djärv<jan.h.d <at> swipnet.se> 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
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.
>
>>> 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 matter
in most cases?
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...
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 09:28:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 15 Jul 2010 10:59:52 +0200, Jan Djärv <jan.h.d <at> swipnet.se> 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 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.
>>
>>> 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
> 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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 09:36:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 5721 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 09:39:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 15 Jul 2010 11:35:37 +0200, Jan Djärv <jan.h.d <at> swipnet.se> 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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 09:58:01 GMT)
Full text and
rfc822 format available.
Message #106 received at 5721 <at> debbugs.gnu.org (full text, mbox):
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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 10:33:02 GMT)
Full text and
rfc822 format available.
Message #109 received at 5721 <at> debbugs.gnu.org (full text, mbox):
YAMAMOTO Mitsuharu skrev 2010-07-15 11.38:
>>>>>> On Thu, 15 Jul 2010 11:35:37 +0200, Jan Djärv<jan.h.d <at> swipnet.se> 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 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?
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 15 Jul 2010 10:57:01 GMT)
Full text and
rfc822 format available.
Message #112 received at 5721 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 16 Jul 2010 00:26:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 15 Jul 2010 12:32:54 +0200, Jan Djärv <jan.h.d <at> swipnet.se> 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.
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 16 Jul 2010 00:36:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 15 Jul 2010 12:56:38 +0200, Jan Djärv <jan.h.d <at> swipnet.se> 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.
2) Call a terminal-specific function that converts frame-relative
coordinates to absolute coordinates. That can be done by the
following "idiom".
x += f->left_pos + FRAME_OUTER_TO_INNER_DIFF_X (f);
y += 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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 16 Jul 2010 06:39:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 5721 <at> debbugs.gnu.org (full text, mbox):
YAMAMOTO Mitsuharu skrev 2010-07-16 02.35:
>>>>>> On Thu, 15 Jul 2010 12:56:38 +0200, Jan Djärv<jan.h.d <at> swipnet.se> 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 += f->left_pos + FRAME_OUTER_TO_INNER_DIFF_X (f);
> y += 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 the
window manager. Top/left does not point at it, it points at the Emacs frame.
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 16 Jul 2010 06:40:02 GMT)
Full text and
rfc822 format available.
Message #124 received at 5721 <at> debbugs.gnu.org (full text, mbox):
YAMAMOTO Mitsuharu skrev 2010-07-16 02.25:
>>>>>> On Thu, 15 Jul 2010 12:32:54 +0200, Jan Djärv<jan.h.d <at> swipnet.se> 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
a function?
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 16 Jul 2010 08:38:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 16 Jul 2010 08:38:44 +0200, Jan Djärv <jan.h.d <at> swipnet.se> said:
>> 2) Call a terminal-specific function that converts frame-relative
>> coordinates to absolute coordinates. That can be done by the
>> following "idiom".
>>
>> x += f->left_pos + FRAME_OUTER_TO_INNER_DIFF_X (f); y += 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.
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
=> 100
3. (window-absolute-pixel-edges) C-j
=> (100 100 756 678)
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 16 Jul 2010 08:49:01 GMT)
Full text and
rfc822 format available.
Message #130 received at 5721 <at> debbugs.gnu.org (full text, mbox):
YAMAMOTO Mitsuharu skrev 2010-07-16 10.37:
>>>>>> On Fri, 16 Jul 2010 08:38:44 +0200, Jan Djärv<jan.h.d <at> swipnet.se> 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
> => 100
> 3. (window-absolute-pixel-edges) C-j
> => (100 100 756 678)
>
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.
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 16 Jul 2010 08:59:02 GMT)
Full text and
rfc822 format available.
Message #133 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 16 Jul 2010 10:49:01 +0200, Jan Djärv <jan.h.d <at> swipnet.se> 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?
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 16 Jul 2010 09:15:02 GMT)
Full text and
rfc822 format available.
Message #136 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 16 Jul 2010 08:39:28 +0200, Jan Djärv <jan.h.d <at> swipnet.se> 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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 16 Jul 2010 12:20:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 5721 <at> debbugs.gnu.org (full text, mbox):
YAMAMOTO Mitsuharu skrev 2010-07-16 10.58:
>>>>>> On Fri, 16 Jul 2010 10:49:01 +0200, Jan Djärv<jan.h.d <at> swipnet.se> 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
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.
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 16 Jul 2010 12:21:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 5721 <at> debbugs.gnu.org (full text, mbox):
YAMAMOTO Mitsuharu skrev 2010-07-16 11.14:
>>>>>> On Fri, 16 Jul 2010 08:39:28 +0200, Jan Djärv<jan.h.d <at> swipnet.se> 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, these
should not be counted. Besides, left_pos and top_pos is not the corners of
the title bar under X.
Jan D.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sat, 17 Jul 2010 00:31:02 GMT)
Full text and
rfc822 format available.
Message #145 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 16 Jul 2010 14:19:21 +0200, Jan Djärv <jan.h.d <at> swipnet.se> 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 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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sat, 17 Jul 2010 05:33:02 GMT)
Full text and
rfc822 format available.
Message #148 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sat, 17 Jul 2010 09:30:43 +0900, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> 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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sat, 17 Jul 2010 08:37:01 GMT)
Full text and
rfc822 format available.
Message #151 received at 5721 <at> debbugs.gnu.org (full text, mbox):
YAMAMOTO Mitsuharu skrev 2010-07-17 07.32:
>>>>>> On Sat, 17 Jul 2010 09:30:43 +0900, YAMAMOTO Mitsuharu<mituharu <at> math.s.chiba-u.ac.jp> 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.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sat, 17 Jul 2010 08:43:02 GMT)
Full text and
rfc822 format available.
Message #154 received at 5721 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sat, 17 Jul 2010 10:37:00 +0200, Jan Djärv <jan.h.d <at> swipnet.se> 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 <at> math.s.chiba-u.ac.jp
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 14 Aug 2010 11:24:03 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
"Andreas Politz, INF|INF-I" <politza <at> hochschule-trier.de>
to
control <at> debbugs.gnu.org.
(Mon, 14 Jan 2013 00:47:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 11 Feb 2013 12:24:03 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Andreas Politz <politza <at> hochschule-trier.de>
to
control <at> debbugs.gnu.org.
(Sat, 28 Sep 2013 18:06:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sat, 28 Sep 2013 20:07:02 GMT)
Full text and
rfc822 format available.
Message #165 received at 5721 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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.
[winabs.diff (text/x-diff, inline)]
=== 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,
[Message part 3 (text/plain, inline)]
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sun, 29 Sep 2013 10:27:01 GMT)
Full text and
rfc822 format available.
Message #168 received at 5721 <at> debbugs.gnu.org (full text, mbox):
> 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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sun, 29 Sep 2013 15:43:01 GMT)
Full text and
rfc822 format available.
Message #171 received at 5721 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sun, 29 Sep 2013 16:00:05 GMT)
Full text and
rfc822 format available.
Message #174 received at 5721 <at> debbugs.gnu.org (full text, mbox):
29 sep 2013 kl. 12:26 skrev martin rudalics <rudalics <at> gmx.at>:
> > 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.
>
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.
Jan D.
> > Suppose no fringes, and header-line. All considerations for a GTK build.
> >
> > 0--------------------------------------*
> > | display |
> > | A----------------------------+ |
> > | | emacs <at> 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
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sun, 29 Sep 2013 16:03:02 GMT)
Full text and
rfc822 format available.
Message #177 received at 5721 <at> debbugs.gnu.org (full text, mbox):
Hello.
29 sep 2013 kl. 17:41 skrev Andreas Politz <politza <at> hochschule-trier.de>:
> martin rudalics <rudalics <at> gmx.at> 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).
>
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.
>
> 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.
Race conditions are common when a window manager is involved. Another reason to keep pixels private and not export them to Elisp.
Jan D..
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sun, 29 Sep 2013 16:06:01 GMT)
Full text and
rfc822 format available.
Message #180 received at 5721 <at> debbugs.gnu.org (full text, mbox):
Hello.
29 sep 2013 kl. 18:02 skrev Jan Djärv <jan.h.d <at> swipnet.se>:
> Hello.
>
> 29 sep 2013 kl. 17:41 skrev Andreas Politz <politza <at> hochschule-trier.de>:
>
>> martin rudalics <rudalics <at> gmx.at> 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).
>>
>
> 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.
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.
>
>>
>> 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.
>
> Race conditions are common when a window manager is involved. Another reason to keep pixels private and not export them to Elisp.
>
> Jan D..
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sun, 29 Sep 2013 17:22:02 GMT)
Full text and
rfc822 format available.
Message #183 received at 5721 <at> debbugs.gnu.org (full text, mbox):
Jan Djärv <jan.h.d <at> swipnet.se> 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 ?
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=no build and it seems
to give the correct values.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sun, 29 Sep 2013 18:10:02 GMT)
Full text and
rfc822 format available.
Message #186 received at 5721 <at> debbugs.gnu.org (full text, mbox):
Hello.
29 sep 2013 kl. 19:21 skrev Andreas Politz <politza <at> hochschule-trier.de>:
> Jan Djärv <jan.h.d <at> swipnet.se> 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 ?
Some versions of Compiz and other composite managers.
>
> 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.
>
>
>>>> [...] 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.
>
> 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
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.
>
> -ap
>
> P.S.: I tried the patch on a bare --with-x-toolkit=no 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sun, 29 Sep 2013 18:48:02 GMT)
Full text and
rfc822 format available.
Message #189 received at 5721 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sun, 29 Sep 2013 18:48:03 GMT)
Full text and
rfc822 format available.
Message #192 received at 5721 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sun, 29 Sep 2013 18:48:04 GMT)
Full text and
rfc822 format available.
Message #195 received at 5721 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sun, 29 Sep 2013 20:11:01 GMT)
Full text and
rfc822 format available.
Message #198 received at 5721 <at> debbugs.gnu.org (full text, mbox):
Hello.
29 sep 2013 kl. 20:47 skrev martin rudalics <rudalics <at> gmx.at>:
> > 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
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Sun, 29 Sep 2013 20:27:01 GMT)
Full text and
rfc822 format available.
Message #201 received at 5721 <at> debbugs.gnu.org (full text, mbox):
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 <rudalics <at> gmx.at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 03 Oct 2013 17:26:02 GMT)
Full text and
rfc822 format available.
Message #204 received at 5721 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[window-absolute-pixel.diff (text/x-diff, inline)]
=== 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
[Message part 3 (text/plain, inline)]
-ap
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 03 Oct 2013 20:26:01 GMT)
Full text and
rfc822 format available.
Message #207 received at 5721 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Politz <politza <at> hochschule-trier.de>
> Date: Thu, 03 Oct 2013 19:25:06 +0200
> Cc: 5721 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Thu, 03 Oct 2013 21:10:02 GMT)
Full text and
rfc822 format available.
Message #210 received at 5721 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 04 Oct 2013 06:49:01 GMT)
Full text and
rfc822 format available.
Message #213 received at 5721 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Politz <politza <at> hochschule-trier.de>
> Cc: jan.h.d <at> swipnet.se, 5721 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 04 Oct 2013 08:29:02 GMT)
Full text and
rfc822 format available.
Message #216 received at 5721 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> 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.
[window-absolute-pixel-v2.diff (text/x-diff, inline)]
=== 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;
[Message part 3 (text/plain, inline)]
-ap
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 04 Oct 2013 08:56:02 GMT)
Full text and
rfc822 format available.
Message #219 received at 5721 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Politz <politza <at> hochschule-trier.de>
> Cc: jan.h.d <at> swipnet.se, 5721 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#5721; Package
emacs.
(Fri, 04 Oct 2013 10:35:01 GMT)
Full text and
rfc822 format available.
Message #222 received at 5721 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> 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.
[window-absolute-pixel-v3.diff (text/x-diff, inline)]
=== 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),
[Message part 3 (text/plain, inline)]
-ap
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 01 Nov 2013 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 238 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.