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

[martin rudalics <rudalics@gmx.at>]

 > 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