GNU bug report logs - #48202
27.2; wrong frame position

Previous Next

Full log

Message #18 received at control <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: ynyaaa <at> gmail.com, 48202 <at> debbugs.gnu.org
Subject: Re: bug#48202: 27.2; wrong frame position
Date: Tue, 04 May 2021 15:06:23 +0300

tags 48202 notabug
close 48202
thanks

> From: martin rudalics <rudalics <at> gmx.at>
> Date: Tue, 4 May 2021 10:08:09 +0200
> 
> I suppose it's those invisible borders which leave an 8 or so pixels
> wide gap.  It's highly annoying, especially when you want to display two
> frames side-by-side and yet another reason not to use Windows 10.

Indeed.  It turns out this is a Windows 10 "feature": the border of
the window used for resizing by mouse is by default invisible (it can
be made visible by changing your desktop theme).  The border is
invisible, but it still takes its space on screen, to allow mouse
resizing.  The details can be found here:

  https://stackoverflow.com/questions/60700133/windows-desktop-coordinate-system-is-off-for-certain-windows?fireglass_rsn=true

> IIRC the Autohotkey people had some sort of fix for it but maybe I
> misremember.

I don't think there should be a fix: this is how the platform behaves,
and intentionally so.

So I don't think this is a bug, and I'm closing this bug report.

> GNOME shell has a similar problem BTW.

Of course, they all copycat each other.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.