GNU bug report logs - #14949
Snapped window acts like a fullscreen one (Windows 7)

Previous Next

To reply to this bug, email your comments to 14949 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: Snapped window acts like a fullscreen one (Windows 7)
Date: Thu, 25 Jul 2013 02:07:18 +0200

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.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14949 <at> debbugs.gnu.org
Subject: Re: bug#14949: Snapped window acts like a fullscreen one (Windows 7)
Date: Sat, 04 Jan 2014 16:42:09 +0100

> 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

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14949 <at> debbugs.gnu.org
Subject: Re: bug#14949: Snapped window acts like a fullscreen one (Windows 7)
Date: Sat, 4 Jan 2014 21:47:38 +0100

On Sat, Jan 4, 2014 at 4:42 PM, martin rudalics <rudalics <at> 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.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14949 <at> debbugs.gnu.org
Subject: Re: bug#14949: Snapped window acts like a fullscreen one (Windows 7)
Date: Sun, 05 Jan 2014 11:37:46 +0100

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

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14949 <at> debbugs.gnu.org
Subject: Re: bug#14949: Snapped window acts like a fullscreen one (Windows 7)
Date: Sun, 5 Jan 2014 18:15:34 +0100

On Sun, Jan 5, 2014 at 11:37 AM, martin rudalics <rudalics <at> 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.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14949 <at> debbugs.gnu.org
Subject: Re: bug#14949: Snapped window acts like a fullscreen one (Windows 7)
Date: Sun, 05 Jan 2014 19:00:20 +0100

> 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

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14949 <at> debbugs.gnu.org
Subject: Re: bug#14949: Snapped window acts like a fullscreen one (Windows 7)
Date: Sun, 5 Jan 2014 19:11:12 +0100

On Sun, Jan 5, 2014 at 7:00 PM, martin rudalics <rudalics <at> 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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14949 <at> debbugs.gnu.org
Subject: Re: bug#14949: Snapped window acts like a fullscreen one (Windows 7)
Date: Sun, 05 Jan 2014 19:39:23 +0100

> 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

Previous Next

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