GNU bug report logs - #16340
24.3.50; Maximize to the left/right side of the screen (on Windows 7 & 8)

Previous Next

Package: emacs;

Reported by: Dani Moncayo <dmoncayo <at> gmail.com>

Date: Sat, 4 Jan 2014 18:59:02 UTC

Severity: minor

Found in version 24.3.50

Done: Dani Moncayo <dmoncayo <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 16340 <at> debbugs.gnu.org
Subject: bug#16340: 24.3.50; Maximize to the left/right side of the screen (on Windows 7 & 8)
Date: Tue, 07 Jan 2014 11:18:55 +0100
> But with 'frame-resize-pixelwise' set to 'nil', a maximized Emacs
> frame takes up the whole "available" screen (except the taskbar),
> without letting any gaps anywhere.

By accident only, I suppose.  Some of my Debian builds seem to resist
fully maximizing the frame unless `frame-resize-pixelwise' is set.  And
bug#16379 seems to confirm such behavior for Windows as well.

> That's why I expected "maximize to
> left/right" to also take the whole left/right half of the available
> screen (without gaps).

It's the call

	      GetClientRect (msg.msg.hwnd, &rect);

on line 4718 of w32term.c that counts here.  Whatever Windows asks us is
what Emacs processes here.  And IIUC (from my experience and what you
told me) Windows sends us non-size-hint-truncated coordinates for a full
maximization request and size-hint-truncated coordinates for a
left/right maximization request.

> But I think that the key difference, which I didn't understand until
> now, may be that "maximize to left/right" (unlike the standard
> "maximize") aren't "states" of a window, i.e. the OS simply tries to
> resize and relocate the window to occupy the corresponding half of the
> screen.

I believe that what we see here is an internal hack of Windows.  That
is, internally, the Aero (or what it is called) part of Windows
maintains the left/right maximized state separate.  You should be able
to verify this by increasing/removing the taskbar or whatever you have
near the Emacs frame.  If the Emacs frame adapts to the change, we know
that Aero/Windows tracks its state.  In any case it seems that Windows
does not communicate that state to the application, probably so because
the API doesn't provide the corresponding feature.

martin




This bug report was last modified 11 years and 184 days ago.

Previous Next


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