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

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

[Dani Moncayo]

Severity: minor

On my Windows 8 system, the "maximize to the left/right" feature of
the OS is not working quite well with Emacs (-Q).  See these
screenshots:

  https://drive.google.com/folderview?id=0B92qXLRvF4ziLUdQNTVFYUFXQm8&usp=sharing

As you can see:

1. When Emacs is maximized to the left ("windows key" + "left arrow"),
there is some residual space at the left and top edges of the Emacs
frame.  There should be no such space.  Compare "emacs-left" (wrong)
with "chrome-left" (ok).

2. When Emacs is maximized to the right ("windows key" + "right
arrow"), there is some residual space at the top edge of the Emacs
frame.  Compare "emacs-right" (wrong) with "chrome-right" (ok).


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2014-01-04 on LEG570
Bzr revision: 115865 rudalics@gmx.at-20140104093130-ccgmn1edhogzfv7l
Windowing system distributor `Microsoft Corp.', version 6.3.9600
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'


-- 
Dani Moncayo

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

[martin rudalics]

 > On my Windows 8 system, the "maximize to the left/right" feature of
 > the OS is not working quite well with Emacs (-Q).  See these
 > screenshots:
 >
 >   https://drive.google.com/folderview?id=0B92qXLRvF4ziLUdQNTVFYUFXQm8&usp=sharing
 >
 > As you can see:
 >
 > 1. When Emacs is maximized to the left ("windows key" + "left arrow"),
 > there is some residual space at the left and top edges of the Emacs
 > frame.  There should be no such space.  Compare "emacs-left" (wrong)
 > with "chrome-left" (ok).
 >
 > 2. When Emacs is maximized to the right ("windows key" + "right
 > arrow"), there is some residual space at the top edge of the Emacs
 > frame.  Compare "emacs-right" (wrong) with "chrome-right" (ok).

If I interpret your caps correctly, the space is created by Windows
itself which tries to obey Emacs' size hints.  Emacs wouldn't adjust the
frame to the right-bottom edge.  Can you try with
`frame-resize-pixelwise' non-nil (either in your .emacs or before
creating a new frame that you want to maximize to the left).

And please tell me the values of (frame-parameter nil 'fullscreen)
before, during and after you left the "maximized to the left" state.  I
need them to investigate Juanma's scenario.

martin

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

[Dani Moncayo]

>  Can you try with
> `frame-resize-pixelwise' non-nil (either in your .emacs or before
> creating a new frame that you want to maximize to the left).

Ok: the new frame I create after setting 'frame-resize-pixelwise' to
't' doesn't have the problem reported in this bug, i.e. that frame
fits exactly in the left/right half of the screen when I do "windows
key" + "left/right arrow".

> And please tell me the values of (frame-parameter nil 'fullscreen)
> before, during and after you left the "maximized to the left" state.

'(frame-parameter nil 'fullscreen)' returns 'nil' before, during and
after the "maximization to the left".

-- 
Dani Moncayo

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

[martin rudalics]

 > Ok: the new frame I create after setting 'frame-resize-pixelwise' to
 > 't' doesn't have the problem reported in this bug, i.e. that frame
 > fits exactly in the left/right half of the screen when I do "windows
 > key" + "left/right arrow".

So all I can say is that Windows obeys your size hints.  If you can live
with pixelwise resized frames (I do so for almost a year now) continue
to do so.  Otherwise you have to live with the gaps.  Tertium non datur.

 >> And please tell me the values of (frame-parameter nil 'fullscreen)
 >> before, during and after you left the "maximized to the left" state.
 >
 > '(frame-parameter nil 'fullscreen)' returns 'nil' before, during and
 > after the "maximization to the left".

Thanks.  This confirms what Juanma told me earlier.

martin

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

[Dani Moncayo]

On Mon, Jan 6, 2014 at 8:58 PM, martin rudalics <rudalics@gmx.at> wrote:
>> Ok: the new frame I create after setting 'frame-resize-pixelwise' to
>> 't' doesn't have the problem reported in this bug, i.e. that frame
>> fits exactly in the left/right half of the screen when I do "windows
>> key" + "left/right arrow".
>
> So all I can say is that Windows obeys your size hints.  If you can live
> with pixelwise resized frames (I do so for almost a year now) continue
> to do so.  Otherwise you have to live with the gaps.  Tertium non datur.

I can live with the gaps, certainly, but I still think that the right
behavior would be not to have those gaps, obviously.

That's my opinion, but mark this bug as "wontfix" and close it if you
want.  I will not complain.  I wanted to report a minor misbehavior I
spotted while playing around; just that.

Thank you.

-- 
Dani Moncayo

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

[martin rudalics]

 > I can live with the gaps, certainly, but I still think that the right
 > behavior would be not to have those gaps, obviously.

If you don't want the gaps, you have to set `frame-resize-pixelwise' to
true.  That's what all other graphical programs on Windows do and that's
what I do.  And that also means that dragging the border of an Emacs
frame will resize it pixelwise like the window of any other graphical
application.

 > That's my opinion, but mark this bug as "wontfix" and close it if you
 > want.  I will not complain.  I wanted to report a minor misbehavior I
 > spotted while playing around; just that.

It is fixed by setting `frame-resize-pixelwise' to t.  So "wontfix"
won't apply ;-)

martin

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

[Dani Moncayo]

> If you don't want the gaps, you have to set `frame-resize-pixelwise' to
> true.  That's what all other graphical programs on Windows do and that's
> what I do.  And that also means that dragging the border of an Emacs
> frame will resize it pixelwise like the window of any other graphical
> application.

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.  That's why I expected "maximize to
left/right" to also take the whole left/right half of the available
screen (without gaps).

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.  In that case, I understand the behavior I see, and I agree it
is not a bug.

I'll close this bug report then.

Thanks for your time.

-- 
Dani Moncayo

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

[Juanma Barranquero]

On Mon, Jan 6, 2014 at 11:16 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:

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

That's not really true, or at least, is not all the truth. Open
Notepad, grab it by the caption, and move it to the left or right;
Windows will "maximize it" to half-display left or right. Then grab it
again from the caption, and move it off the side of the display:
Windows restores its previous size. So the half-maximized left/right
is some sort of state of a window, it's not just a resizing, because
on a normal resizing Windows does not remember the previous dimensions
of the window. Vertical maximization (Win+Shift+Up) is also a
"sort-of-maximized" state that can be restored with Win+Shift-Down.

     J

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

[Dani Moncayo]

>> "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.
>
> That's not really true, or at least, is not all the truth. Open
> Notepad, grab it by the caption, and move it to the left or right;
> Windows will "maximize it" to half-display left or right. Then grab it
> again from the caption, and move it off the side of the display:
> Windows restores its previous size. So the half-maximized left/right
> is some sort of state of a window, it's not just a resizing, because
> on a normal resizing Windows does not remember the previous dimensions
> of the window. Vertical maximization (Win+Shift+Up) is also a
> "sort-of-maximized" state that can be restored with Win+Shift-Down.

Duh, you're right Juanma.  (I should have deferred my reply to Martin
until after sleeping :).)

Therefore, I think that the questions now are: if these ("maximized to
left/right") are special states of a window, could Emacs keep track of
them?  And if so, could Emacs DTRT (i.e. avoid the gaps) when they are
active?

-- 
Dani Moncayo

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

[martin rudalics]

 > Therefore, I think that the questions now are: if these ("maximized to
 > left/right") are special states of a window, could Emacs keep track of
 > them?

I'm afraid the answer is no.  But maybe Juanma finds out something about
this.

 > And if so, could Emacs DTRT (i.e. avoid the gaps) when they are
 > active?

If the API does communicate them to us, yes.  But still I think that
setting `frame-resize-pixelwise' to t is much simpler in that case.

martin

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

[martin rudalics]

 > That's not really true, or at least, is not all the truth. Open
 > Notepad, grab it by the caption, and move it to the left or right;
 > Windows will "maximize it" to half-display left or right. Then grab it
 > again from the caption, and move it off the side of the display:
 > Windows restores its previous size. So the half-maximized left/right
 > is some sort of state of a window, it's not just a resizing, because
 > on a normal resizing Windows does not remember the previous dimensions
 > of the window. Vertical maximization (Win+Shift+Up) is also a
 > "sort-of-maximized" state that can be restored with Win+Shift-Down.

Can/do we trigger that "restore" from emacs?

martin

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

[martin rudalics]

 > 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

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

[Daniel Colascione]

On 01/06/2014 02:03 PM, martin rudalics wrote:
>  > I can live with the gaps, certainly, but I still think that the right
>  > behavior would be not to have those gaps, obviously.
>
> If you don't want the gaps, you have to set `frame-resize-pixelwise' to
> true.  That's what all other graphical programs on Windows do and that's
> what I do.  And that also means that dragging the border of an Emacs
> frame will resize it pixelwise like the window of any other graphical
> application.
>
>  > That's my opinion, but mark this bug as "wontfix" and close it if you
>  > want.  I will not complain.  I wanted to report a minor misbehavior I
>  > spotted while playing around; just that.
>
> It is fixed by setting `frame-resize-pixelwise' to t.  So "wontfix"
> won't apply ;-)

By the way: M-: (setq frame-resize-pixelwise t) seems to affect new 
frames, but not the current one. Is that expected behavior?

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

[martin rudalics]

 > By the way: M-: (setq frame-resize-pixelwise t) seems to affect new
 > frames, but not the current one. Is that expected behavior?

It should affect the current one as soon as the next size hint request
iss passed to the window manager.  We could force that by sending an
explicit x_wm_set_size_hint whenever we set that variable but so far I
have not bothered to do that.  Also, I'm not sure either whether we
should make this a frame parameter.  Suggestions welcome.

martin

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

[Stephen Berman]

On Tue, 07 Jan 2014 11:19:18 +0100 martin rudalics <rudalics@gmx.at> wrote:

>> By the way: M-: (setq frame-resize-pixelwise t) seems to affect new
>> frames, but not the current one. Is that expected behavior?
>
> It should affect the current one as soon as the next size hint request
> iss passed to the window manager.

Is there an Emacs command or function that induces such a hint, or any
user manipulation of the current frame?  Just dragging the edge of the
frame does not make it resize pixelwise, whereas with a new frame that
works immediately.

Steve Berman

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

[martin rudalics]

 > Is there an Emacs command or function that induces such a hint,

The intended use of the option is via .emacs.  Did you try that?

 > or any
 > user manipulation of the current frame?  Just dragging the edge of the
 > frame does not make it resize pixelwise, whereas with a new frame that
 > works immediately.

It should work after the first resize operation (at least it does so
here) because that sets the hint.  Maybe I should write a function that
allows to set the hints manually at least for the base, minimum, maximum
sizes and the increments.  After the release.

martin

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

[Stephen Berman]

On Tue, 07 Jan 2014 18:31:58 +0100 martin rudalics <rudalics@gmx.at> wrote:

>> Is there an Emacs command or function that induces such a hint,
>
> The intended use of the option is via .emacs.  Did you try that?

I just did, and it does indeed work as you say.  Shouldn't the doc
string of frame-resize-pixelwise say it must be set in the user's init
file to affect the initial frame?

Steve Berman

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

[martin rudalics]

> I just did, and it does indeed work as you say.  Shouldn't the doc
> string of frame-resize-pixelwise say it must be set in the user's init
> file to affect the initial frame?

Done in revision 115972.

martin

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

[martin rudalics]

 > By the way: M-: (setq frame-resize-pixelwise t) seems to affect new
 > frames, but not the current one.

It affects the current one _after_ the first resize operation on it.

 > Is that expected behavior?

Yes.  This option should be rather used only in .emacs.  It expresses a
global preference of the user, should not be bound or set interactively.

martin