* Patch to fix frame positioning with negative top/left values on Windows
@ 2005-07-07 16:23 Francis Litterio
2005-07-09 0:30 ` Francis Litterio
2006-04-01 7:44 ` Patch to fix frame positioning with negative top/left values onWindows Drew Adams
0 siblings, 2 replies; 11+ messages in thread
From: Francis Litterio @ 2005-07-07 16:23 UTC (permalink / raw)
Cc: help-emacs-windows
Emacs developers,
This patch to the CVS Emacs sources fixes the way that function
x_calc_absolute_position() accounts for the Windows-drawn borders around
a frame when converting a negative 'top or 'left parameter into the
equivalent positive value.
I have submitted this patch before, but RMS told me that the FSF needed
a copyright assignment from me before it could applied. The FSF now has
mysigned the copyright assignment, so please let me know if there's any
problem with this patch. I've been running Emacs with it for some
months with no problems.
--
Francis Litterio
franl <at> world . std . com
diff -w -u -u -w -r1.228 w32term.c
--- w32term.c 4 Jul 2005 16:06:37 -0000 1.228
+++ w32term.c 7 Jul 2005 16:19:39 -0000
@@ -5438,17 +5438,58 @@
{
int flags = f->size_hint_flags;
- /* Treat negative positions as relative to the leftmost bottommost
+ /* left_right_borders_width holds the sum of the widths of the frame's left
+ and right borders (in pixels) drawn by Windows. */
+
+ unsigned int left_right_borders_width = 8; /* A sensible default value. */
+
+ /* top_bottom_borders_height holds the sum of the heights of the frame's top and
+ bottom borders (in pixels) drawn by Windows. */
+
+ unsigned int top_bottom_borders_height = 32; /* A sensible default value. */
+
+ /* Now obtain the actual values of the above two variables. If we fail to
+ obtain the actual values, we will use the defaults assigned above. We compute
+ the border width (height) by subtracting the width (height) of the frame's
+ client area from the width (height) of the frame's entire window.
+ */
+
+ WINDOWPLACEMENT wp = { 0 };
+
+ BOOL status = GetWindowPlacement (FRAME_W32_WINDOW (f), &wp);
+
+ if (status != FALSE)
+ {
+ RECT client_rect = { 0 };
+
+ status = GetClientRect (FRAME_W32_WINDOW (f), &client_rect);
+
+ if (status != FALSE)
+ {
+ left_right_borders_width =
+ (wp.rcNormalPosition.right - wp.rcNormalPosition.left) -
+ (client_rect.right - client_rect.left);
+
+ top_bottom_borders_height =
+ (wp.rcNormalPosition.bottom - wp.rcNormalPosition.top) -
+ (client_rect.bottom - client_rect.top);
+ }
+ }
+
+ /* Treat negative positions as relative to the rightmost bottommost
position that fits on the screen. */
if (flags & XNegative)
f->left_pos = (FRAME_W32_DISPLAY_INFO (f)->width
- FRAME_PIXEL_WIDTH (f)
- + f->left_pos);
+ + f->left_pos
+ - (left_right_borders_width - 1));
if (flags & YNegative)
f->top_pos = (FRAME_W32_DISPLAY_INFO (f)->height
- FRAME_PIXEL_HEIGHT (f)
- + f->top_pos);
+ + f->top_pos
+ - (top_bottom_borders_height - 1));
+
/* The left_pos and top_pos
are now relative to the top and left screen edges,
so the flags should correspond. */
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Patch to fix frame positioning with negative top/left values on Windows
2005-07-07 16:23 Patch to fix frame positioning with negative top/left values on Windows Francis Litterio
@ 2005-07-09 0:30 ` Francis Litterio
2005-07-09 8:07 ` Jason Rumney
2006-04-01 7:44 ` Patch to fix frame positioning with negative top/left values onWindows Drew Adams
1 sibling, 1 reply; 11+ messages in thread
From: Francis Litterio @ 2005-07-09 0:30 UTC (permalink / raw)
Cc: help-emacs-windows
I wrote:
> This patch to the CVS Emacs sources fixes the way that function
> x_calc_absolute_position() accounts for the Windows-drawn borders around
> a frame when converting a negative 'top or 'left parameter into the
> equivalent positive value.
I should have said what the symptom of the malfunction is that, on
Windows, when you evaluate this Elisp code:
(make-frame '((top . -1) (left . -1)))
the new frame will not be positioned with its bottom-right corner in the
bottom-right of the display.
My patch fixes this, even in the case where the use configures
non-standard vertical or horizontal frame border sizes.
Sorry for the confusion.
--
Francis Litterio
franl <at> world . std . com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Patch to fix frame positioning with negative top/left values on Windows
2005-07-09 0:30 ` Francis Litterio
@ 2005-07-09 8:07 ` Jason Rumney
2005-07-09 15:16 ` Re: Patch to fix frame positioning with negative top/leftvalues " Drew Adams
0 siblings, 1 reply; 11+ messages in thread
From: Jason Rumney @ 2005-07-09 8:07 UTC (permalink / raw)
Cc: help-emacs-windows, emacs-devel
Francis Litterio <franl@world.std.com> writes:
> I should have said what the symptom of the malfunction is that, on
> Windows, when you evaluate this Elisp code:
>
> (make-frame '((top . -1) (left . -1)))
>
> the new frame will not be positioned with its bottom-right corner in the
> bottom-right of the display.
I think that will break display on multiple monitors, where the second
monitor is to the left or above the main monitor. We have already had
bug reports about the mouse wheel not working in such a configuration,
so people do use it.
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Re: Patch to fix frame positioning with negative top/leftvalues on Windows
2005-07-09 8:07 ` Jason Rumney
@ 2005-07-09 15:16 ` Drew Adams
2005-07-09 19:38 ` Jason Rumney
2005-07-10 5:19 ` Richard M. Stallman
0 siblings, 2 replies; 11+ messages in thread
From: Drew Adams @ 2005-07-09 15:16 UTC (permalink / raw)
Cc: help-emacs-windows, emacs-devel
> I should have said what the symptom of the malfunction is that, on
> Windows, when you evaluate this Elisp code:
>
> (make-frame '((top . -1) (left . -1)))
>
> the new frame will not be positioned with its bottom-right
corner in the
> bottom-right of the display.
I think that will break display on multiple monitors, where the second
monitor is to the left or above the main monitor. We have already had
bug reports about the mouse wheel not working in such a configuration,
so people do use it.
I don't understand your reply, sorry. Are you saying that Francis's bug fix
will break "..." or that the reported bug (symptom quoted above) will break
"..."? Are you saying we shouldn't try to fix this bug because that might
break something else?
This bug exists. I don't know if Francis's fix fixes it 100% or whether his
fix might break something else, but the bug is real.
Again, sorry if I'm misunderstanding.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Patch to fix frame positioning with negative top/leftvalues on Windows
2005-07-09 15:16 ` Re: Patch to fix frame positioning with negative top/leftvalues " Drew Adams
@ 2005-07-09 19:38 ` Jason Rumney
2005-07-10 1:17 ` Francis Litterio
2005-07-10 5:19 ` Richard M. Stallman
1 sibling, 1 reply; 11+ messages in thread
From: Jason Rumney @ 2005-07-09 19:38 UTC (permalink / raw)
Cc: Francis Litterio, help-emacs-windows, emacs-devel
"Drew Adams" <drew.adams@oracle.com> writes:
> > Windows, when you evaluate this Elisp code:
> >
> > (make-frame '((top . -1) (left . -1)))
> >
> > the new frame will not be positioned with its bottom-right
> corner in the
> > bottom-right of the display.
> I don't understand your reply, sorry. Are you saying that Francis's bug fix
> will break "..." or that the reported bug (symptom quoted above) will break
> "..."? Are you saying we shouldn't try to fix this bug because that might
> break something else?
I didn't understand the bug fix. I thought it was changing the way the
frame was positioned when negative arguments are given, however it
seems that misfeature already exists, and this fix was only a subtle
change to that misfeature. So this bug fix is not the problem, it is
the misfeature of treating negative coordinates specially.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Patch to fix frame positioning with negative top/leftvalues on Windows
2005-07-09 19:38 ` Jason Rumney
@ 2005-07-10 1:17 ` Francis Litterio
0 siblings, 0 replies; 11+ messages in thread
From: Francis Litterio @ 2005-07-10 1:17 UTC (permalink / raw)
Cc: help-emacs-windows
Jason Rumney wrote:
> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> > Windows, when you evaluate this Elisp code:
>> >
>> > (make-frame '((top . -1) (left . -1)))
>> >
>> > the new frame will not be positioned with its bottom-right
>> corner in the
>> > bottom-right of the display.
>
>> I don't understand your reply, sorry. Are you saying that Francis's bug fix
>> will break "..." or that the reported bug (symptom quoted above) will break
>> "..."? Are you saying we shouldn't try to fix this bug because that might
>> break something else?
>
> I didn't understand the bug fix. I thought it was changing the way the
> frame was positioned when negative arguments are given, however it
> seems that misfeature already exists, and this fix was only a subtle
> change to that misfeature. So this bug fix is not the problem, it is
> the misfeature of treating negative coordinates specially.
Are you proposing that the meaning of a negative 'top or 'left frame
parameter should be changed? If so, how?
My patch merely attempts to make negative 'top and 'left frame
parameters behave sanely in the case where a single monitor is used
(which is the vast majority of the use cases).
--
Francis Litterio
franl <at> world . std . com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Patch to fix frame positioning with negative top/leftvalues on Windows
2005-07-09 15:16 ` Re: Patch to fix frame positioning with negative top/leftvalues " Drew Adams
2005-07-09 19:38 ` Jason Rumney
@ 2005-07-10 5:19 ` Richard M. Stallman
1 sibling, 0 replies; 11+ messages in thread
From: Richard M. Stallman @ 2005-07-10 5:19 UTC (permalink / raw)
Cc: franl, help-emacs-windows, emacs-devel, jasonr
This bug exists. I don't know if Francis's fix fixes it 100% or whether his
fix might break something else, but the bug is real.
I suppose the patch could be adapted so as to DTRT for the multi-monitor
case.
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Patch to fix frame positioning with negative top/left values onWindows
2005-07-07 16:23 Patch to fix frame positioning with negative top/left values on Windows Francis Litterio
2005-07-09 0:30 ` Francis Litterio
@ 2006-04-01 7:44 ` Drew Adams
2006-04-01 16:22 ` Fran Litterio
1 sibling, 1 reply; 11+ messages in thread
From: Drew Adams @ 2006-04-01 7:44 UTC (permalink / raw)
I've been using a 2005-06-26 CVS snapshot on Windows that had this bug. I
thought that this had been fixed since that snapshot. I just tried a
2006-03-20 snapshot on Windows, however, and the same bug is still there.
Did Fran's patch never get applied, or doesn't it work? His patch dates from
January of 2005 - soon to be a year and a half! The bug symptoms are the
same as before. See thread "Improved patch to fix frame positioning bug on
Windows" from 2005-01-14.
-----Original Message-----
From: emacs-devel-bounces+drew.adams=oracle.com@gnu.org
[mailto:emacs-devel-bounces+drew.adams=oracle.com@gnu.org]On Behalf Of
Francis Litterio
Sent: Thursday, July 07, 2005 9:24 AM
To: emacs-devel@gnu.org
Cc: help-emacs-windows@gnu.org
Subject: Patch to fix frame positioning with negative top/left values
onWindows
Emacs developers,
This patch to the CVS Emacs sources fixes the way that function
x_calc_absolute_position() accounts for the Windows-drawn borders around
a frame when converting a negative 'top or 'left parameter into the
equivalent positive value.
I have submitted this patch before, but RMS told me that the FSF needed
a copyright assignment from me before it could applied. The FSF now has
mysigned the copyright assignment, so please let me know if there's any
problem with this patch. I've been running Emacs with it for some
months with no problems.
--
Francis Litterio
franl <at> world . std . com
diff -w -u -u -w -r1.228 w32term.c
--- w32term.c 4 Jul 2005 16:06:37 -0000 1.228
+++ w32term.c 7 Jul 2005 16:19:39 -0000
@@ -5438,17 +5438,58 @@
{
int flags = f->size_hint_flags;
- /* Treat negative positions as relative to the leftmost bottommost
+ /* left_right_borders_width holds the sum of the widths of
the frame's left
+ and right borders (in pixels) drawn by Windows. */
+
+ unsigned int left_right_borders_width = 8; /* A sensible
default value. */
+
+ /* top_bottom_borders_height holds the sum of the heights of
the frame's top and
+ bottom borders (in pixels) drawn by Windows. */
+
+ unsigned int top_bottom_borders_height = 32; /* A sensible
default value. */
+
+ /* Now obtain the actual values of the above two variables.
If we fail to
+ obtain the actual values, we will use the defaults
assigned above. We compute
+ the border width (height) by subtracting the width
(height) of the frame's
+ client area from the width (height) of the frame's entire window.
+ */
+
+ WINDOWPLACEMENT wp = { 0 };
+
+ BOOL status = GetWindowPlacement (FRAME_W32_WINDOW (f), &wp);
+
+ if (status != FALSE)
+ {
+ RECT client_rect = { 0 };
+
+ status = GetClientRect (FRAME_W32_WINDOW (f), &client_rect);
+
+ if (status != FALSE)
+ {
+ left_right_borders_width =
+ (wp.rcNormalPosition.right - wp.rcNormalPosition.left) -
+ (client_rect.right - client_rect.left);
+
+ top_bottom_borders_height =
+ (wp.rcNormalPosition.bottom - wp.rcNormalPosition.top) -
+ (client_rect.bottom - client_rect.top);
+ }
+ }
+
+ /* Treat negative positions as relative to the rightmost bottommost
position that fits on the screen. */
if (flags & XNegative)
f->left_pos = (FRAME_W32_DISPLAY_INFO (f)->width
- FRAME_PIXEL_WIDTH (f)
- + f->left_pos);
+ + f->left_pos
+ - (left_right_borders_width - 1));
if (flags & YNegative)
f->top_pos = (FRAME_W32_DISPLAY_INFO (f)->height
- FRAME_PIXEL_HEIGHT (f)
- + f->top_pos);
+ + f->top_pos
+ - (top_bottom_borders_height - 1));
+
/* The left_pos and top_pos
are now relative to the top and left screen edges,
so the flags should correspond. */
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Patch to fix frame positioning with negative top/left values onWindows
2006-04-01 7:44 ` Patch to fix frame positioning with negative top/left values onWindows Drew Adams
@ 2006-04-01 16:22 ` Fran Litterio
2006-04-02 20:38 ` Richard Stallman
0 siblings, 1 reply; 11+ messages in thread
From: Fran Litterio @ 2006-04-01 16:22 UTC (permalink / raw)
Cc: Drew Adams
I just checked the CVS archive, and my patch has not been applied.
I've been running with it for well over a year with no negative
side-effects. I would like to see it applied.
--
Fran Litterio
On 4/1/06, Drew Adams <drew.adams@oracle.com> wrote:
> I've been using a 2005-06-26 CVS snapshot on Windows that had this bug. I
> thought that this had been fixed since that snapshot. I just tried a
> 2006-03-20 snapshot on Windows, however, and the same bug is still there.
>
> Did Fran's patch never get applied, or doesn't it work? His patch dates from
> January of 2005 - soon to be a year and a half! The bug symptoms are the
> same as before. See thread "Improved patch to fix frame positioning bug on
> Windows" from 2005-01-14.
>
> -----Original Message-----
> From: emacs-devel-bounces+drew.adams=oracle.com@gnu.org
> [mailto:emacs-devel-bounces+drew.adams=oracle.com@gnu.org]On Behalf Of
> Francis Litterio
> Sent: Thursday, July 07, 2005 9:24 AM
> To: emacs-devel@gnu.org
> Cc: help-emacs-windows@gnu.org
> Subject: Patch to fix frame positioning with negative top/left values
> onWindows
>
> Emacs developers,
>
> This patch to the CVS Emacs sources fixes the way that function
> x_calc_absolute_position() accounts for the Windows-drawn borders around
> a frame when converting a negative 'top or 'left parameter into the
> equivalent positive value.
>
> I have submitted this patch before, but RMS told me that the FSF needed
> a copyright assignment from me before it could applied. The FSF now has
> mysigned the copyright assignment, so please let me know if there's any
> problem with this patch. I've been running Emacs with it for some
> months with no problems.
> --
> Francis Litterio
> franl <at> world . std . com
>
>
> diff -w -u -u -w -r1.228 w32term.c
> --- w32term.c 4 Jul 2005 16:06:37 -0000 1.228
> +++ w32term.c 7 Jul 2005 16:19:39 -0000
> @@ -5438,17 +5438,58 @@
> {
> int flags = f->size_hint_flags;
>
> - /* Treat negative positions as relative to the leftmost bottommost
> + /* left_right_borders_width holds the sum of the widths of
> the frame's left
> + and right borders (in pixels) drawn by Windows. */
> +
> + unsigned int left_right_borders_width = 8; /* A sensible
> default value. */
> +
> + /* top_bottom_borders_height holds the sum of the heights of
> the frame's top and
> + bottom borders (in pixels) drawn by Windows. */
> +
> + unsigned int top_bottom_borders_height = 32; /* A sensible
> default value. */
> +
> + /* Now obtain the actual values of the above two variables.
> If we fail to
> + obtain the actual values, we will use the defaults
> assigned above. We compute
> + the border width (height) by subtracting the width
> (height) of the frame's
> + client area from the width (height) of the frame's entire window.
> + */
> +
> + WINDOWPLACEMENT wp = { 0 };
> +
> + BOOL status = GetWindowPlacement (FRAME_W32_WINDOW (f), &wp);
> +
> + if (status != FALSE)
> + {
> + RECT client_rect = { 0 };
> +
> + status = GetClientRect (FRAME_W32_WINDOW (f), &client_rect);
> +
> + if (status != FALSE)
> + {
> + left_right_borders_width =
> + (wp.rcNormalPosition.right - wp.rcNormalPosition.left) -
> + (client_rect.right - client_rect.left);
> +
> + top_bottom_borders_height =
> + (wp.rcNormalPosition.bottom - wp.rcNormalPosition.top) -
> + (client_rect.bottom - client_rect.top);
> + }
> + }
> +
> + /* Treat negative positions as relative to the rightmost bottommost
> position that fits on the screen. */
> if (flags & XNegative)
> f->left_pos = (FRAME_W32_DISPLAY_INFO (f)->width
> - FRAME_PIXEL_WIDTH (f)
> - + f->left_pos);
> + + f->left_pos
> + - (left_right_borders_width - 1));
>
> if (flags & YNegative)
> f->top_pos = (FRAME_W32_DISPLAY_INFO (f)->height
> - FRAME_PIXEL_HEIGHT (f)
> - + f->top_pos);
> + + f->top_pos
> + - (top_bottom_borders_height - 1));
> +
> /* The left_pos and top_pos
> are now relative to the top and left screen edges,
> so the flags should correspond. */
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Patch to fix frame positioning with negative top/left values onWindows
2006-04-01 16:22 ` Fran Litterio
@ 2006-04-02 20:38 ` Richard Stallman
2006-04-03 1:23 ` Fran Litterio
0 siblings, 1 reply; 11+ messages in thread
From: Richard Stallman @ 2006-04-02 20:38 UTC (permalink / raw)
Cc: drew.adams, emacs-devel
I just checked the CVS archive, and my patch has not been applied.
I've been running with it for well over a year with no negative
side-effects. I would like to see it applied.
Is this the change that we just had a discussion about?
Or is this a different one?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Patch to fix frame positioning with negative top/left values onWindows
2006-04-02 20:38 ` Richard Stallman
@ 2006-04-03 1:23 ` Fran Litterio
0 siblings, 0 replies; 11+ messages in thread
From: Fran Litterio @ 2006-04-03 1:23 UTC (permalink / raw)
On 4/2/06, Richard Stallman wrote:
> I just checked the CVS archive, and my patch has not been applied.
> I've been running with it for well over a year with no negative
> side-effects. I would like to see it applied.
>
> Is this the change that we just had a discussion about?
> Or is this a different one?
It's a different one. This one fixes improper frame positioning on
Windows when negative X or Y offsets are supplied. It fixes a bug
where passing the value -1 would not position the edge of the window
decorations exactly at the right or bottom of the screen.
--
Francis Litterio
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2006-04-03 1:23 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-07-07 16:23 Patch to fix frame positioning with negative top/left values on Windows Francis Litterio
2005-07-09 0:30 ` Francis Litterio
2005-07-09 8:07 ` Jason Rumney
2005-07-09 15:16 ` Re: Patch to fix frame positioning with negative top/leftvalues " Drew Adams
2005-07-09 19:38 ` Jason Rumney
2005-07-10 1:17 ` Francis Litterio
2005-07-10 5:19 ` Richard M. Stallman
2006-04-01 7:44 ` Patch to fix frame positioning with negative top/left values onWindows Drew Adams
2006-04-01 16:22 ` Fran Litterio
2006-04-02 20:38 ` Richard Stallman
2006-04-03 1:23 ` Fran Litterio
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).