bug#14949: Snapped window acts like a fullscreen one (Windows 7)

bug#14949: Snapped window acts like a fullscreen one (Windows 7)

[Juanma Barranquero]

Package: emacs
Version: 24.3.50

emacs -Q
Win + left arrow
M-: (frame-parameter nil 'fullscreen)   => nil
M-: (set-frame-parameter nil 'fullscreen nil)

The frame is "restored" to a default size.

So the frame, when snapped to the left or rigth, acts like a
(fullscreen . fullheight) one, but it is not marked as such.

bug#14949: Snapped window acts like a fullscreen one (Windows 7)

[martin rudalics]

 > emacs -Q
 > Win + left arrow

What does this do - move the frame to the left display border or make it
fullheight/fullwidth?

 > M-: (frame-parameter nil 'fullscreen)   => nil
 > M-: (set-frame-parameter nil 'fullscreen nil)
 >
 > The frame is "restored" to a default size.

Why is that bad?

 > So the frame, when snapped to the left or rigth, acts like a
 > (fullscreen . fullheight) one, but it is not marked as such.

If you refer to fullheight/fullwidth frames they have to act this way.
We could consider fullheight/fullwidth frames as "normal" but

(1) Windows doesn't know such frames so it can't handle them, and

(2) Emacs, if considering them normal, would forget about the previous
     normal size and you couldn't easily switch between
     fullheight/fullwidth and normal size any more.

But maybe I misunderstand what you want to do.

martin

bug#14949: Snapped window acts like a fullscreen one (Windows 7)

[Juanma Barranquero]

On Sat, Jan 4, 2014 at 4:42 PM, martin rudalics <rudalics@gmx.at> wrote:

>> Win + left arrow
>
> What does this do - move the frame to the left display border or make it
> fullheight/fullwidth?

It moves the frame to the left display border, and resizes it to
fullheight and half-width (so you can type Win+right into another
application and have the apps use the full screen side by side).

>> M-: (frame-parameter nil 'fullscreen)   => nil
>> M-: (set-frame-parameter nil 'fullscreen nil)
>>
>> The frame is "restored" to a default size.
>
> Why is that bad?

Because `frame-parameter' just told us that the frame wasn't
full-anything, so setting it again to fullscreen = nil shouldn't
change it, should it? Or, alternatively, restoring the frame to its
previous size is useful, but then I would expect that, after Win+left,
(frame-parameter nil 'fullscreen) => fullheight

Which is what I said:

>> So the frame, when snapped to the left or rigth, acts like a
>> (fullscreen . fullheight) one, but it is not marked as such.

bug#14949: Snapped window acts like a fullscreen one (Windows 7)

[martin rudalics]

 >>> Win + left arrow
 >> What does this do - move the frame to the left display border or make it
 >> fullheight/fullwidth?
 >
 > It moves the frame to the left display border, and resizes it to
 > fullheight and half-width (so you can type Win+right into another
 > application and have the apps use the full screen side by side).

But does this mean that your Emacs also sets the fullscreen parameter to
FULLHEIGHT when it processes the request?  Can you describe how Emacs
processes this request internally?

 >>> M-: (frame-parameter nil 'fullscreen)   => nil
 >>> M-: (set-frame-parameter nil 'fullscreen nil)
 >>>
 >>> The frame is "restored" to a default size.
 >> Why is that bad?
 >
 > Because `frame-parameter' just told us that the frame wasn't
 > full-anything, so setting it again to fullscreen = nil shouldn't
 > change it, should it?

Agreed.

 > Or, alternatively, restoring the frame to its
 > previous size is useful, but then I would expect that, after Win+left,
 > (frame-parameter nil 'fullscreen) => fullheight

Agreed.

 > Which is what I said:
 >
 >>> So the frame, when snapped to the left or rigth, acts like a
 >>> (fullscreen . fullheight) one, but it is not marked as such.

I'm still too silly to understand what's going on.  Let me give you a
simple example: With emacs -Q resize your frame by dragging its borders.
Then evaluate (set-frame-parameter nil 'fullscreen nil).  Here nothing
changes.  Does anything change on your system?

So apparently Win+left does something different than "simply dragging
the frame's borders" and I yet have to understand what.  What happens
when you remove the

       else
         {
	  ShowWindow (hwnd, SW_SHOWNORMAL);
	  w32_fullscreen_rect (hwnd, f->want_fullscreen,
			       FRAME_NORMAL_PLACEMENT (f).rcNormalPosition, &rect);
           SetWindowPos (hwnd, HWND_TOP, rect.left, rect.top,
                         rect.right - rect.left, rect.bottom - rect.top, 0);
         }

part in w32fullscreen_hook?

martin

bug#14949: Snapped window acts like a fullscreen one (Windows 7)

[Juanma Barranquero]

On Sun, Jan 5, 2014 at 11:37 AM, martin rudalics <rudalics@gmx.at> wrote:

> But does this mean that your Emacs also sets the fullscreen parameter to
> FULLHEIGHT when it processes the request?

No, of course not.

> I'm still too silly to understand what's going on.  Let me give you a
> simple example: With emacs -Q resize your frame by dragging its borders.
> Then evaluate (set-frame-parameter nil 'fullscreen nil).  Here nothing
> changes.  Does anything change on your system?

No. Neither resizing the frame by hand nor using Win+left (or
Win+right) modifies the fullscreen frame parameter. That's what I'm
describing as a bug:

Case 1:
emacs -Q
resize by hand
M-: (frame-parameter nil 'fullscreen) => nil
M-: (set-frame-parameter nil 'fullscreen nil) => nothing changes

Case 2:
emacs -Q
Win+Left
M-: (frame-parameter nil 'fullscreen) => nil
M-: (set-frame-parameter nil 'fullscreen nil)
  => the pre-Win+left frame size and position is restored

> What happens when you remove the [...] part in w32fullscreen_hook?

Nothing different.

bug#14949: Snapped window acts like a fullscreen one (Windows 7)

[martin rudalics]

 > No. Neither resizing the frame by hand nor using Win+left (or
 > Win+right) modifies the fullscreen frame parameter. That's what I'm
 > describing as a bug:
 >
 > Case 1:
 > emacs -Q
 > resize by hand
 > M-: (frame-parameter nil 'fullscreen) => nil
 > M-: (set-frame-parameter nil 'fullscreen nil) => nothing changes
 >
 > Case 2:
 > emacs -Q
 > Win+Left
 > M-: (frame-parameter nil 'fullscreen) => nil
 > M-: (set-frame-parameter nil 'fullscreen nil)
 >   => the pre-Win+left frame size and position is restored

But that's precisely the mystery.  It clearly indicates that Win+Left
does something different than just setting the frame size and position
and I don't have the slightest idea what that could be.

For example, if I here first evaluate

(modify-frame-parameters
  nil '((height . 61) (width . 80) (top . 0) (left . 0)))

which gives my frame the same height as FULLHEIGHT and then evaluate

(set-frame-parameter nil 'fullscreen nil)

that doesn't change anything.  Can you understand the mystery?

martin

bug#14949: Snapped window acts like a fullscreen one (Windows 7)

[Juanma Barranquero]

On Sun, Jan 5, 2014 at 7:00 PM, martin rudalics <rudalics@gmx.at> wrote:

> Can you understand the mystery?

If I had to guess, I'd bet that when the window is snapped (that's how
the feature is called, Aero Snap), Windows remembers that it is
sort-of-maximized (to make de-snapping possible). So if we pass
SW_SHOWNORMAL ("If the window is minimized or maximized, the system
restores it to its original size and position") to ShowWindow, Windows
restores the frame; then Emacs gets hold of the (new) size and
position.

Does that make any sense?

    J

bug#14949: Snapped window acts like a fullscreen one (Windows 7)

[martin rudalics]

 > If I had to guess, I'd bet that when the window is snapped (that's how
 > the feature is called, Aero Snap), Windows remembers that it is
 > sort-of-maximized (to make de-snapping possible). So if we pass
 > SW_SHOWNORMAL ("If the window is minimized or maximized, the system
 > restores it to its original size and position") to ShowWindow, Windows
 > restores the frame; then Emacs gets hold of the (new) size and
 > position.
 >
 > Does that make any sense?

It does.  You should be able to verify this by debugging it.  Or better
by investigating the WINDOWPLACEMENT structure.  Then you can try to
replace SW_SHOWNORMAL by SW_RESTORE.  If that doesn't help either we are
probably lost.

martin