GNU bug report logs - #14180
PATCH Better fullscreen frame support on Windows

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14180 in the body.
You can then email your comments to 14180 AT debbugs.gnu.org in the normal way.

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

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

From: Erik Charlebois <erikcharlebois <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: PATCH Better fullscreen frame support on Windows
Date: Thu, 11 Apr 2013 00:59:54 -0400

[Message part 1 (text/plain, inline)]

Description

This change improves the 'fullscreen' frame support on Windows. When going
to
fullscreen, the frame gets fullscreened with no window decorations (which
causes the
Windows task bar to also disappear) on the nearest monitor.

The old fullscreen functionality was actually 'maximize' behavior so I've
moved that to
'maximize'. 'fullwidth' and 'fullheight' are now ignored because they were
buggy (at least in
Windows 8, they were not being sized correctly) and are not common Windows
idioms.
While they could be supported, I'd do it as follow on work and get it
working right on
multiple monitors as well.

I've tested corner cases such as resolution changes and disconnect
monitors; in both
cases the fullscreen window stays fullscreen (and moves to a different
monitor for the
disconnect case).

I've modified the response to WM_WINDOWPOSCHANGED to do nothing when the
frame is fullscreen. Otherwise, the size gets tuned to a multiple of the
character cells and
the fullscreen isn't perfectly matching the screen. When this happens,
Windows' special
behavior to hide the taskbar doesn't kick in.

Changelog

2013-04-11  Erik Charlebois  <erikcharlebois <at> gmail.com>

* src/w32fns.c (monitor_from_window_fn): New Windows API import.
(w32_monitor_rect): New function to get nearest monitor rect.
* src/w32term.c (w32_fullscreen_hook): Renamed from w32fullscreen_hook
for consistency. Rewritten for improved fullscreen support.


(I signed the FSF copyright assignment papers in January so I'm ok on that
front.)

[Message part 2 (text/html, inline)]

[W32_FULLSCREEN.txt (text/plain, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Erik Charlebois <erikcharlebois <at> gmail.com>
Cc: 14180 <at> debbugs.gnu.org
Subject: Re: bug#14180: PATCH Better fullscreen frame support on Windows
Date: Fri, 12 Apr 2013 11:28:46 +0200

> I've modified the response to WM_WINDOWPOSCHANGED to do nothing when the
> frame is fullscreen. Otherwise, the size gets tuned to a multiple of the
> character cells and
> the fullscreen isn't perfectly matching the screen. When this happens,
> Windows' special
> behavior to hide the taskbar doesn't kick in.

I suppose that any remaining pixels go to the mode line which will have
a slightly shorter scrollbar if the pixel height of your monitor is not
a multiple of FRAME_LINE_HEIGHT.  Can you observe that?

martin

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

From: Erik Charlebois <erikcharlebois <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14180 <at> debbugs.gnu.org
Subject: Re: bug#14180: PATCH Better fullscreen frame support on Windows
Date: Fri, 12 Apr 2013 15:32:08 -0400

[Message part 1 (text/plain, inline)]

That's correct. The modeline scrollbar is slightly clipped.

I just doubled checked toggling scrollbars, menubar and toolbar on and off
while in fullscreen and it all works as expected.

Thanks for the reminder since I usually run with all those elements off :).


On Fri, Apr 12, 2013 at 5:28 AM, martin rudalics <rudalics <at> gmx.at> wrote:

> > I've modified the response to WM_WINDOWPOSCHANGED to do nothing when the
> > frame is fullscreen. Otherwise, the size gets tuned to a multiple of the
> > character cells and
> > the fullscreen isn't perfectly matching the screen. When this happens,
> > Windows' special
> > behavior to hide the taskbar doesn't kick in.
>
> I suppose that any remaining pixels go to the mode line which will have
> a slightly shorter scrollbar if the pixel height of your monitor is not
> a multiple of FRAME_LINE_HEIGHT.  Can you observe that?
>
> martin
>

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Erik Charlebois <erikcharlebois <at> gmail.com>
Cc: 14180 <at> debbugs.gnu.org
Subject: Re: bug#14180: PATCH Better fullscreen frame support on Windows
Date: Sat, 13 Apr 2013 10:03:09 +0200

> That's correct. The modeline scrollbar is slightly clipped.

It's because we currently do not distribute spare pixel lines to other
windows but simply append them at the end of the mode-line without,
however, storing the pixel height in the window.  The display engine
doesn't know anything about this and therefore cannot draw the scroll
bar long enough.  I suppose the remaining pixel lines of the screen are
cleared by Windows using FRAME_BACKGROUND_PIXEL but never checked that.
Here I changed the behavior by appending the extra pixel lines to the
windows that "most need it".

> I just doubled checked toggling scrollbars, menubar and toolbar on and off
> while in fullscreen and it all works as expected.
>
> Thanks for the reminder since I usually run with all those elements off :).

I intended to ask you that too.  At least some of these can have very
nasty delayed effects (at least with the old maximized/fullscreen mode).
In particular, independently setting margin widths and scrollbar widths
and the internal border widths of frames.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Erik Charlebois <erikcharlebois <at> gmail.com>
Cc: 14180 <at> debbugs.gnu.org
Subject: Re: bug#14180: PATCH Better fullscreen frame support on Windows
Date: Sat, 13 Apr 2013 13:09:50 +0300

> Date: Thu, 11 Apr 2013 00:59:54 -0400
> From: Erik Charlebois <erikcharlebois <at> gmail.com>
> 
> This change improves the 'fullscreen' frame support on Windows. When
> going to fullscreen, the frame gets fullscreened with no window
> decorations (which causes the Windows task bar to also disappear) on
> the nearest monitor.

Thank you for doing this.

Jan, does the fullscreen functionality on X also maximizes the frame
to one of the monitors, when several monitors are available?  I don't
want to introduce differences in behavior here.

> The old fullscreen functionality was actually 'maximize' behavior so
> I've moved that to 'maximize'.

Sorry, I don't understand.  The value of the 'fullscreen' frame
parameter can be either 'maximize' or 'fullboth' (the latter also has
a confusing alias 'fullscreen').  The current trunk code handles both,
and it does so in accordance with the documentation (the last sentence
below):

  `fullscreen'
       Specify that width, height or both shall be maximized.  The value
       `fullwidth' specifies that width shall be as wide as possible.
       The value `fullheight' specifies that height shall be as tall as
       possible.  The value `fullboth' specifies that both the width and
       the height shall be set to the size of the screen.  The value
       `maximized' specifies that the frame shall be maximized.  The
       difference between `maximized' and `fullboth' is that the former
       can still be resized by dragging window manager decorations with
       the mouse, while the latter really covers the whole screen and
       does not allow resizing by mouse dragging.

It looks like your patch swaps the meaning of 'fullboth' and
'maximize', so that Emacs on MS-Windows will behave differently from
its behavior on other platforms.  Is my understanding correct?  If so,
please don't make that swap, it is wrong.

> 'fullwidth' and 'fullheight' are now ignored because they were buggy
> (at least in Windows 8, they were not being sized correctly) and are
> not common Windows idioms.

Please don't ignore these two values.  They do work reasonably well on
XP and on Windows 7.  If they are buggy and/or don't work on Windows
8, let's fix them if we can, and leave them as they are if we can't
fix them.  Removing them is too drastic, IMO; I see no justification
for that.

> While they could be supported, I'd do it as follow on work and get
> it working right on multiple monitors as well.

Thanks, but in the meantime please don't remove the current code that
attempts to support these two values.

> I've modified the response to WM_WINDOWPOSCHANGED to do nothing when
> the frame is fullscreen. Otherwise, the size gets tuned to a
> multiple of the character cells and the fullscreen isn't perfectly
> matching the screen. When this happens, Windows' special behavior to
> hide the taskbar doesn't kick in.

During debugging the new code, I saw that w32_fullscreen_hook is
called with f->want_fullscreen set to the value FULLSCREEN_WAIT; I'm
not sure your code expects that value and/or handles it correctly.
Please double-check that.

> (I signed the FSF copyright assignment papers in January so I'm ok on that
> front.)

Unfortunately, the FSF records still don't reflect your assignment, as
of this writing.  Could you please write to the FSF clerk with whom
you were in touch, and ask him to expedite the update?  Thanks.

A few comments about your patch:

> 2013-04-11  Erik Charlebois  <erikcharlebois <at> gmail.com>
> 
> * src/w32fns.c (monitor_from_window_fn): New Windows API import.
> (w32_monitor_rect): New function to get nearest monitor rect.
> * src/w32term.c (w32_fullscreen_hook): Renamed from w32fullscreen_hook
> for consistency. Rewritten for improved fullscreen support.

Please leave 2 spaces after a period that ends a sentence (we use the
US conventions in ChangeLogs and in the docs.)

Also, please don't rename w32fullscreen_hook, I see no reason for
consistency in naming functions that are private to the w32 build.

> +void
> +w32_monitor_rect (struct frame *f, RECT *rect)
> +{
> +#ifdef HAVE_WINDOW_SYSTEM
> +  if (f)
> +    {
> +      /* If multiple monitor support is available, make the window
> +         fullscreen on the appropriate screen. */
                                                 ^
Two spaces here.

Also, is there really a reason for the ifdef?  I don't think this code
could possibly be called in a -nw session, could it?

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14180 <at> debbugs.gnu.org, Erik Charlebois <erikcharlebois <at> gmail.com>
Subject: Re: bug#14180: PATCH Better fullscreen frame support on Windows
Date: Sat, 13 Apr 2013 13:33:56 +0200

2013-04-13 12:09, Eli Zaretskii skrev:

>
> Jan, does the fullscreen functionality on X also maximizes the frame
> to one of the monitors, when several monitors are available?  I don't
> want to introduce differences in behavior here.
>

If there is a window manager running, we just tell the window manager to make 
Emacs fullscreen, so it is really up to the WM.  The window managers I worked 
with do maximize on one monitor only.

When no WM is running we maximize to the whole display, i.e. all monitors. 
But that is more or less just for debugging when you want to see Emacs <-> 
Xserver interractions without a WM getting in the way.  It is nothing a user 
ever encounters.

	Jan D.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 14180 <at> debbugs.gnu.org, erikcharlebois <at> gmail.com
Subject: Re: bug#14180: PATCH Better fullscreen frame support on Windows
Date: Sat, 13 Apr 2013 14:56:52 +0300

> Date: Sat, 13 Apr 2013 13:33:56 +0200
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> CC: Erik Charlebois <erikcharlebois <at> gmail.com>, 14180 <at> debbugs.gnu.org
> 
> 2013-04-13 12:09, Eli Zaretskii skrev:
> 
> >
> > Jan, does the fullscreen functionality on X also maximizes the frame
> > to one of the monitors, when several monitors are available?  I don't
> > want to introduce differences in behavior here.
> >
> 
> If there is a window manager running, we just tell the window manager to make 
> Emacs fullscreen, so it is really up to the WM.  The window managers I worked 
> with do maximize on one monitor only.
> 
> When no WM is running we maximize to the whole display, i.e. all monitors. 
> But that is more or less just for debugging when you want to see Emacs <-> 
> Xserver interractions without a WM getting in the way.  It is nothing a user 
> ever encounters.

OK, thanks.  So I guess that part of Erik's patch is fine.

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

From: Erik Charlebois <erikcharlebois <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14180 <at> debbugs.gnu.org
Subject: Re: bug#14180: PATCH Better fullscreen frame support on Windows
Date: Sat, 13 Apr 2013 21:23:16 -0400

[Message part 1 (text/plain, inline)]

I've rewritten the patch to preserve the maximized, fullwidth and
fullheight functionality and fix them
on Windows 8; came out cleaner in the end too.

The FULLSCREEN_WAIT flag now gets cleared prior to using want_fullscreen
(was a bug in the
existing implementation too I believe).

I've contacted the FSF clerk. Hopefully that can get cleared up soon.

2013-04-11  Erik Charlebois  <erikcharlebois <at> gmail.com>

* src/w32fns.c (w32_fullscreen_rect): New function to compute the
window rectangle for the given fullscreen mode.
(w32_wnd_proc): When in a fullscreen mode, WM_WINDOWPOSCHANGING
no longer tunes the window size.  This keeps the window's edges
flush with the screen and allows the taskbar to hide itself in
fullboth.
* src/w32term.c (w32fullscreen_hook): fullboth now shows without
window decorations and uses the entire screen.


On Sat, Apr 13, 2013 at 7:56 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Sat, 13 Apr 2013 13:33:56 +0200
> > From: Jan Djärv <jan.h.d <at> swipnet.se>
> > CC: Erik Charlebois <erikcharlebois <at> gmail.com>, 14180 <at> debbugs.gnu.org
> >
> > 2013-04-13 12:09, Eli Zaretskii skrev:
> >
> > >
> > > Jan, does the fullscreen functionality on X also maximizes the frame
> > > to one of the monitors, when several monitors are available?  I don't
> > > want to introduce differences in behavior here.
> > >
> >
> > If there is a window manager running, we just tell the window manager to
> make
> > Emacs fullscreen, so it is really up to the WM.  The window managers I
> worked
> > with do maximize on one monitor only.
> >
> > When no WM is running we maximize to the whole display, i.e. all
> monitors.
> > But that is more or less just for debugging when you want to see Emacs
> <->
> > Xserver interractions without a WM getting in the way.  It is nothing a
> user
> > ever encounters.
>
> OK, thanks.  So I guess that part of Erik's patch is fine.
>

[Message part 2 (text/html, inline)]

[W32_FULLSCREEN_2.txt (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Erik Charlebois <erikcharlebois <at> gmail.com>
Cc: 14180 <at> debbugs.gnu.org
Subject: Re: bug#14180: PATCH Better fullscreen frame support on Windows
Date: Sun, 14 Apr 2013 09:41:18 +0300

> Date: Sat, 13 Apr 2013 21:23:16 -0400
> From: Erik Charlebois <erikcharlebois <at> gmail.com>
> Cc: 14180 <at> debbugs.gnu.org
> 
> I've rewritten the patch to preserve the maximized, fullwidth and
> fullheight functionality and fix them
> on Windows 8; came out cleaner in the end too.

Thank you!

> I've contacted the FSF clerk. Hopefully that can get cleared up soon.

Thanks.  The moment your assignment is on file, these changes can go
in.

Thanks again for working on this.

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

From: Erik Charlebois <erikcharlebois <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14180 <at> debbugs.gnu.org
Subject: Re: bug#14180: PATCH Better fullscreen frame support on Windows
Date: Fri, 19 Apr 2013 20:42:43 -0400

[Message part 1 (text/plain, inline)]

Hi Eli,

The assignment should be on file now.


On Sun, Apr 14, 2013 at 2:41 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Sat, 13 Apr 2013 21:23:16 -0400
> > From: Erik Charlebois <erikcharlebois <at> gmail.com>
> > Cc: 14180 <at> debbugs.gnu.org
> >
> > I've rewritten the patch to preserve the maximized, fullwidth and
> > fullheight functionality and fix them
> > on Windows 8; came out cleaner in the end too.
>
> Thank you!
>
> > I've contacted the FSF clerk. Hopefully that can get cleared up soon.
>
> Thanks.  The moment your assignment is on file, these changes can go
> in.
>
> Thanks again for working on this.
>

[Message part 2 (text/html, inline)]

Message #37 received at 14180-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Erik Charlebois <erikcharlebois <at> gmail.com>
Cc: 14180-done <at> debbugs.gnu.org
Subject: Re: bug#14180: PATCH Better fullscreen frame support on Windows
Date: Sat, 20 Apr 2013 10:36:55 +0300

> Date: Fri, 19 Apr 2013 20:42:43 -0400
> From: Erik Charlebois <erikcharlebois <at> gmail.com>
> Cc: 14180 <at> debbugs.gnu.org
> 
> The assignment should be on file now.

Indeed, it is.  Therefore, I committed your changes as trunk revision
112337.

A few comments on your ChangeLog entries (for the future; I fixed all
of the issues mentioned below):

  . We have a separate ChangeLog in src, so the file names should not
    include "src/".

  . The entries for different files should be separated by an empty
    line.

  . Each non-empty line should begin with a TAB.

  . You forgot to describe the changes in w32term.h.

FYI, here are the log entries I committed in your name:

  2013-04-20  Erik Charlebois  <erikcharlebois <at> gmail.com>

	  * w32fns.c (w32_fullscreen_rect): New function to compute the
	  window rectangle for the given fullscreen mode.
	  (w32_wnd_proc): When in a fullscreen mode, WM_WINDOWPOSCHANGING no
	  longer tunes the window size.  This keeps the window's edges flush
	  with the screen and allows the taskbar to hide itself in fullboth.

	  * w32term.c (w32fullscreen_hook): 'fullboth' now shows without
	  window decorations and uses the entire screen.

	  * w32term.h  (w32_fullscreen_rect) Add prototype.
	  (struct w32_output): Replace normal_width, normal_height,
	  normal_top, and normal_left members with a single normal_placement
	  struct.
	  (FRAME_NORMAL_WIDTH, FRAME_NORMAL_HEIGHT, FRAME_NORMAL_TOP):
	  Remove macros.
	  (FRAME_NORMAL_PLACEMENT): New macro.


Thanks again for working on this.

I'm marking this bug as done.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 14180 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org, erikcharlebois <at> gmail.com
Subject: Re: bug#14180: PATCH Better fullscreen frame support on Windows
Date: Sat, 20 Apr 2013 10:34:54 -0400

>   . The entries for different files should be separated by an empty
>     line.

BTW, while that's what we usually do, it's sometimes useful to eliminate
the line as an indication that the changes are inter-dependent.


        Stefan

Previous Next

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