bug#25542: 25.1; Restoring the frame from fullscreen to maximized

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

Dani Moncayo
Recipe from "emacs -Q"

1. Maximize the frame using the mouse -- for example, on MS-Windows,
either click on the "maximize" button or double click on the title
bar.

2. Switch to fullscreen by pressing F11.

3. Press F11 again.


Expected behavior: The frame goes to its previous state (i.e. maximized).

Observed behavior: The frame is not maximized (it is smaller that a
maximized one, both in height and width).


I'm using the Emacs distributed with cygwin, which uses the native
MS-Windows GUI (package "emacs-w32"):

In GNU Emacs 25.1.1 (x86_64-unknown-cygwin)
 of 2016-09-17 built on desktop-new
Windowing system distributor 'Microsoft Corp.', version 10.0.10586
Configured using:
 'configure
 --srcdir=/home/kbrown/src/cygemacs/emacs-25.1-1.x86_64/src/emacs-25.1
 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
 --docdir=/usr/share/doc/emacs --htmldir=/usr/share/doc/emacs/html -C
 --with-w32 'CFLAGS=-ggdb -O2 -pipe -Wimplicit-function-declaration
 -fdebug-prefix-map=/home/kbrown/src/cygemacs/emacs-25.1-1.x86_64/build=/usr/src/debug/emacs-25.1-1
 -fdebug-prefix-map=/home/kbrown/src/cygemacs/emacs-25.1-1.x86_64/src/emacs-25.1=/usr/src/debug/emacs-25.1-1'
 CPPFLAGS= LDFLAGS='

Configured features:
XPM JPEG TIFF GIF PNG IMAGEMAGICK SOUND DBUS NOTIFY ACL GNUTLS LIBXML2
ZLIB TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

--
Dani Moncayo



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

martin rudalics
 > Recipe from "emacs -Q"
 >
 > 1. Maximize the frame using the mouse -- for example, on MS-Windows,
 > either click on the "maximize" button or double click on the title
 > bar.
 >
 > 2. Switch to fullscreen by pressing F11.
 >
 > 3. Press F11 again.
 >
 >
 > Expected behavior: The frame goes to its previous state (i.e. maximized).

This is the behavior I get with my MinGW builds on Windows XP.

 > Observed behavior: The frame is not maximized (it is smaller that a
 > maximized one, both in height and width).
 >
 >
 > I'm using the Emacs distributed with cygwin, which uses the native
 > MS-Windows GUI (package "emacs-w32"):

What is that package "emacs-w32"?

martin



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

Dani Moncayo
>> I'm using the Emacs distributed with cygwin, which uses the native
>> MS-Windows GUI (package "emacs-w32"):
>
> What is that package "emacs-w32"?

I'm not sure I understand your question, so my answer may be
trivial/useless to you, but anyway:  Cygwin is a distribution of
software organized in packages.  The name of one of those packages is
"emacs-w32" (you can search for it in the cygwin package manager).
Well, that is the package which includes the Emacs binary I'm using.
It's basically a build of Emacs made for the Cygwin platform, but
modified to use the native MS-Windows GUI, instead of X-Window or
another toolkit like GTK+.

HTH.

--
Dani Moncayo



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

Dani Moncayo
BTW, I forgot to mention that my OS (on which Cygwin is installed) is
MS-Windows 10 Enterprise.

--
Dani Moncayo



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

martin rudalics
In reply to this post by Dani Moncayo
 >> What is that package "emacs-w32"?
 >
 > I'm not sure I understand your question, so my answer may be
 > trivial/useless to you, but anyway:  Cygwin is a distribution of
 > software organized in packages.  The name of one of those packages is
 > "emacs-w32" (you can search for it in the cygwin package manager).
 > Well, that is the package which includes the Emacs binary I'm using.

I don't have Cygwin installed so I doubt that using its package manager
would make much sense for me.  Anyway, I suppose it provides a w32
executable, say emacs-w32.exe and some additional libraries.  I was a
bit confused by the term "package".

 > It's basically a build of Emacs made for the Cygwin platform, but
 > modified to use the native MS-Windows GUI, instead of X-Window or
 > another toolkit like GTK+.

We would probably have to look at these "modifications" in order to find
out what happens.  Meanwhile a few questions:

(1) What is the appearance of the maximize button after step 3?  Does it
     show two overlapping windows or one large window?

(2) How do the frames from before step 2 and after step 3 differ?
     Please use M-: (frame-geometry) and post the ‘outer-position’ and
     ‘outer-size’ values.

(3) Apart from the problem you reported do

     M-: (set-frame-parameter nil 'fullscreen 'maximized)

     and clicking on the maximize button of the title bar produce frames
     with the same size and position?

(4) Does setting ‘frame-resize-pixelwise’ to t change anything?

(5) Can you try with a native Windows build or a GTK build and see
     whether they exhibit the same problem?

 > BTW, I forgot to mention that my OS (on which Cygwin is installed) is
 > MS-Windows 10 Enterprise.

Can anyone with a native build on Windows 10 reproduce the problem?

Thanks, martin




Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

Noam Postavsky-2
On Thu, Jan 26, 2017 at 9:00 AM, martin rudalics <[hidden email]> wrote:
>
>> BTW, I forgot to mention that my OS (on which Cygwin is installed) is
>> MS-Windows 10 Enterprise.
>
> Can anyone with a native build on Windows 10 reproduce the problem?

Does not reproduce for me on Windows 10 using the native 25.1 release
or master from a few days ago.



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

Eli Zaretskii
In reply to this post by martin rudalics
> Date: Thu, 26 Jan 2017 10:51:48 +0100
> From: martin rudalics <[hidden email]>
>
>  > Recipe from "emacs -Q"
>  >
>  > 1. Maximize the frame using the mouse -- for example, on MS-Windows,
>  > either click on the "maximize" button or double click on the title
>  > bar.
>  >
>  > 2. Switch to fullscreen by pressing F11.
>  >
>  > 3. Press F11 again.
>  >
>  >
>  > Expected behavior: The frame goes to its previous state (i.e. maximized).
>
> This is the behavior I get with my MinGW builds on Windows XP.

As do I.  I also tested on Windows 7, and I see the same expected
behavior there.



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

Eli Zaretskii
In reply to this post by Noam Postavsky-2
> From: Noam Postavsky <[hidden email]>
> Date: Thu, 26 Jan 2017 10:43:29 -0500
> Cc: [hidden email]
>
> On Thu, Jan 26, 2017 at 9:00 AM, martin rudalics <[hidden email]> wrote:
> >
> >> BTW, I forgot to mention that my OS (on which Cygwin is installed) is
> >> MS-Windows 10 Enterprise.
> >
> > Can anyone with a native build on Windows 10 reproduce the problem?
>
> Does not reproduce for me on Windows 10 using the native 25.1 release
> or master from a few days ago.

That's strange, since the Cygwin w32 build is supposed to use the same
code as the native build for its GUI display backend.

Maybe Dani could test a native build on the same system?



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

Dani Moncayo
In reply to this post by Dani Moncayo
Hello,

I've just realized another detail required to reproduce the problem:
the Windows taskbar must be docked to the left side of the screen.
(If I move the taskbar to the bottom side --its default position--,
then I cannot reproduce the problem).

I've just reproduced the problem also with a native MS-Windows build
of Emacs (a recent build from the emacs-25 branch):

  In GNU Emacs 25.1.90.1 (i686-pc-mingw32)
   of 2016-12-28 built on LEG570
  Repository revision: 697167b5432a89db009238cf5cbddc61e69ad339
  Windowing system distributor 'Microsoft Corp.', version 10.0.14393
  Configured using:
   'configure --host=i686-pc-mingw32'

--
Dani Moncayo



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

Noam Postavsky-2
On Thu, Jan 26, 2017 at 12:49 PM, Dani Moncayo <[hidden email]> wrote:
> Hello,
>
> I've just realized another detail required to reproduce the problem:
> the Windows taskbar must be docked to the left side of the screen.
> (If I move the taskbar to the bottom side --its default position--,
> then I cannot reproduce the problem).
>
> I've just reproduced the problem also with a native MS-Windows build
> of Emacs (a recent build from the emacs-25 branch):

I can confirm with 25.1 and master. Oddly enough, having the taskbar
on the *right* side of screen (which I usually do) doesn't trigger
this issue either.



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

martin rudalics
In reply to this post by Dani Moncayo
 > I've just realized another detail required to reproduce the problem:
 > the Windows taskbar must be docked to the left side of the screen.
 > (If I move the taskbar to the bottom side --its default position--,
 > then I cannot reproduce the problem).
 >
 > I've just reproduced the problem also with a native MS-Windows build
 > of Emacs (a recent build from the emacs-25 branch):

What does M-: (w32-display-monitor-attributes-list) return when your
taskbar is on the left?

Do other applications handle your scenario correctly?  Firefox?

martin



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

Dani Moncayo
Hi Martin,

> What does M-: (w32-display-monitor-attributes-list) return when your
> taskbar is on the left?

(((geometry 0 0 1600 900) (workarea 62 0 1538 900) (mm-size 443 249)
(name . "\\\\.\\DISPLAY1") (frames #<frame emacs@CPX-L6Q03C31DOX
0x10100bc30>)))

> Do other applications handle your scenario correctly?  Firefox?

I've just tested the chrome browser, and the File Explorer.  Both
behave correctly.

--
Dani Moncayo



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

Dani Moncayo
In reply to this post by martin rudalics
> (1) What is the appearance of the maximize button after step 3?  Does it
>     show two overlapping windows or one large window?

The button shows a single box.- i.e., the window state is _not_ maximized.

> (2) How do the frames from before step 2 and after step 3 differ?
>     Please use M-: (frame-geometry) and post the ‘outer-position’ and
>     ‘outer-size’ values.

The frames are exactly equal.  Both in size and positon on the screen.

> (3) Apart from the problem you reported do
>
>     M-: (set-frame-parameter nil 'fullscreen 'maximized)
>
>     and clicking on the maximize button of the title bar produce frames
>     with the same size and position?

Yes.  Both are maximized frames, which take up the entire screen
except the taskbar.

> (4) Does setting ‘frame-resize-pixelwise’ to t change anything?

No (the problem persists after setting that variable to t).

> (5) Can you try with a native Windows build or a GTK build and see
>     whether they exhibit the same problem?

This was answered in a previous mail.  The problem is reproducible
also with a native windows build.

--
Dani Moncayo



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

Eli Zaretskii
> From: Dani Moncayo <[hidden email]>
> Date: Fri, 27 Jan 2017 09:03:41 +0100
> Cc: [hidden email]
>
> > (2) How do the frames from before step 2 and after step 3 differ?
> >     Please use M-: (frame-geometry) and post the ‘outer-position’ and
> >     ‘outer-size’ values.
>
> The frames are exactly equal.  Both in size and positon on the screen.

This seems to contradict your original report, where you said the two
frames had different sizes.  Or maybe you are saying that the above 2
functions return the same values, but the actual values are different?



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

Dani Moncayo
>> > (2) How do the frames from before step 2 and after step 3 differ?
>> >     Please use M-: (frame-geometry) and post the ‘outer-position’ and
>> >     ‘outer-size’ values.
>>
>> The frames are exactly equal.  Both in size and positon on the screen.
>
> This seems to contradict your original report, where you said the two
> frames had different sizes.

Mmmm I said this:

  Observed behavior: The frame is not maximized (it is smaller that a
  maximized one, both in height and width).

So I don't see any contradiction - What I wanted to express in both
cases is that the Emacs frame, after the final step, is _not_
maximized (as it should be).

IOW: in step 3, the frame should have been switched from fullscreen to
maximized, but it actually switched to the initial status/size (i.e.
not maximized).

HTH

--
Dani Moncayo



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

martin rudalics
In reply to this post by Dani Moncayo
 >> What does M-: (w32-display-monitor-attributes-list) return when your
 >> taskbar is on the left?
 >
 > (((geometry 0 0 1600 900) (workarea 62 0 1538 900) (mm-size 443 249)
 > (name . "\\\\.\\DISPLAY1") (frames #<frame emacs@CPX-L6Q03C31DOX
 > 0x10100bc30>)))

So the taskbar is recognized correctly.

Thanks, martin



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

martin rudalics
In reply to this post by Dani Moncayo
 >> (1) What is the appearance of the maximize button after step 3?  Does it
 >>      show two overlapping windows or one large window?
 >
 > The button shows a single box.- i.e., the window state is _not_ maximized.

This should not happen.  Does it show the two boxes after step 3 with
the taskbar placed on any of the three other sides of your screen?

 >> (2) How do the frames from before step 2 and after step 3 differ?
 >>      Please use M-: (frame-geometry) and post the ‘outer-position’ and
 >>      ‘outer-size’ values.
 >
 > The frames are exactly equal.  Both in size and positon on the screen.

Please post the values, maybe they can give us a clue.

Thanks, martin




Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

Dani Moncayo
On Fri, Jan 27, 2017 at 10:19 AM, martin rudalics <[hidden email]> wrote:
>>> (1) What is the appearance of the maximize button after step 3?  Does it
>>>      show two overlapping windows or one large window?
>>
>> The button shows a single box.- i.e., the window state is _not_ maximized.
>
> This should not happen.  Does it show the two boxes after step 3 with
> the taskbar placed on any of the three other sides of your screen?

I've just tried with the taskbar on the bottom side, and yes, it does
show the two boxes (i.e., maximized frame, expected behavior).

>>> (2) How do the frames from before step 2 and after step 3 differ?
>>>      Please use M-: (frame-geometry) and post the ‘outer-position’ and
>>>      ‘outer-size’ values.
>>
>> The frames are exactly equal.  Both in size and positon on the screen.
>
> Please post the values, maybe they can give us a clue.

In both cases (before step 2 and after step 3), (frame-geometry) outputs this:

  ((outer-position 192 . 130) (outer-size 689 . 671)
(external-border-size 8 . 8) (title-bar-size 651 . 23)
(menu-bar-external . t) (menu-bar-size 673 . 20) (tool-bar-external)
(tool-bar-position . top) (tool-bar-size 689 . 36)
(internal-border-width . 0))


--
Dani Moncayo



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

Dani Moncayo
BTW/FWIW: I've now tried to reproduce the problem with the taskbar
placed at every possible side (left, right, top, bottom).  I see the
problem with the taskbar in the left or top.  I do _not_ see the
problem with the taskbar in the bottom or right.

HTH

--
Dani Moncayo



Reply | Threaded
Open this post in threaded view
|

bug#25542: 25.1; Restoring the frame from fullscreen to maximized

martin rudalics
In reply to this post by Dani Moncayo
 > I've just tried with the taskbar on the bottom side, and yes, it does
 > show the two boxes (i.e., maximized frame, expected behavior).

Can you try the other two sides as well?

 > In both cases (before step 2 and after step 3), (frame-geometry) outputs this:
 >
 >    ((outer-position 192 . 130)

This completely contradicts what I have seen till now: outer-position
should be negative on at least one side (in your case the value 130
should be something like -4 accounting for the external border width).

What's even more strange is that it shows this value before step 2.
This seems to indicate that the frame was not maximized before step 2
either.  What are the respective values with the taskbar on bottom?

 > (outer-size 689 . 671)

Is it true that your screen is almost square and has so few pixels?

martin



123