Patch to fix frame positioning with negative top/left values on Windows

Patch to fix frame positioning with negative top/left values on Windows

[Francis Litterio]

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.  */

Re: Patch to fix frame positioning with negative top/left values on Windows

[Francis Litterio]

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

Re: Patch to fix frame positioning with negative top/left values on Windows

[Jason Rumney]

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.

RE: Re: Patch to fix frame positioning with negative top/leftvalues on Windows

[Drew Adams]

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

Re: Re: Patch to fix frame positioning with negative top/leftvalues on Windows

[Jason Rumney]

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

Re: Patch to fix frame positioning with negative top/leftvalues on Windows

[Francis Litterio]

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

Re: Re: Patch to fix frame positioning with negative top/leftvalues on Windows

[Richard M. Stallman]

    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.

RE: Patch to fix frame positioning with negative top/left values onWindows

[Drew Adams]

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

Re: Patch to fix frame positioning with negative top/left values onWindows

[Fran Litterio]

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

Re: Patch to fix frame positioning with negative top/left values onWindows

[Richard Stallman]

    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?

Re: Patch to fix frame positioning with negative top/left values onWindows

[Fran Litterio]

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