GNU bug report logs - #13935
24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 13935 <at> debbugs.gnu.org, jan.h.d <at> swipnet.se
Subject: Re: bug#13935: 24.3.50;
	`fullscreen' frame parameter is wrong, on MS Windows at least
Date: Fri, 15 Mar 2013 17:41:16 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <13935 <at> debbugs.gnu.org>
> Date: Fri, 15 Mar 2013 08:15:24 -0700
> 
> 2. You might (dunno) also want to say that whether or not all of the described
> behavior is realized exactly as stated can depend on the window mgr.  IOW, as it
> is written now, it says that Emacs will do something, and it does not exactly do
> that in all cases.
> 
> E.g., as the bug report mentioned, the frame on MS Windows is (currently) not
> "as wide as possible".

It does that "as well as it can".

> And on Windows fullboth is not "the size of the screen"
> (because of the task bar and the width gap mentioned).

Well, if we want to go pedantic, then "the screen size" was never
formally defined.  Any reasonable definition must keep the task bar
visible, so I'd actually argue that the text is reasonably accurate.

> 3. And as I said, it certainly is possible to get fullwidth on Windows to DTRT.
> The frame-cmds.el code I pointed to uses the full screen width - no 0.5cm gap.
> (And it allows for the accessible part of the screen, e.g., lets users exclude
> or not the Windows task bar and Mac stuff - see function
> `available-screen-pixel-bounds'.)

People can use your frame-cmds.el code, until someone figures out how
to do all that on the C level and in the framework of how Emacs reacts
to changes of frame parameters.

Previous Next

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