* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
@ 2013-03-12 20:44 Drew Adams
2013-03-12 21:25 ` Eli Zaretskii
0 siblings, 1 reply; 21+ messages in thread
From: Drew Adams @ 2013-03-12 20:44 UTC (permalink / raw)
To: 13935
emacs -Q
M-: (modify-frame-parameters nil '((fullscreen . fullboth)))
The frame is not wide enough - about a centimeter too narrow.
M-: (modify-frame-parameters nil '((fullscreen . maximized)))
This does maximize the frame.
However, the Elisp manual, node `Size Parameters', is incorrect in
saying that either `maximized' or `fullboth' does not have
window-manager decorations.
Beyond that, I suspect that the text is anyway mistaken wrt the order,
and that what was meant was that `fullboth', not `maximized, still has
decorations. Dunno about that, however.
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
of 2013-03-04 on ODIEONE
Bzr revision: 111935 yamaoka@jpl.org-20130304102733-4qy111z41qwoh2as
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.7) --no-opt --enable-checking --cflags
-IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-12 20:44 bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least Drew Adams
@ 2013-03-12 21:25 ` Eli Zaretskii
2013-03-12 21:59 ` Drew Adams
2013-03-12 22:38 ` Drew Adams
0 siblings, 2 replies; 21+ messages in thread
From: Eli Zaretskii @ 2013-03-12 21:25 UTC (permalink / raw)
To: Drew Adams; +Cc: 13935
> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 12 Mar 2013 13:44:04 -0700
>
>
> emacs -Q
>
> M-: (modify-frame-parameters nil '((fullscreen . fullboth)))
>
> The frame is not wide enough - about a centimeter too narrow.
That is the best I could do (on my system, the difference is much less
than 1 cm, FWIW). Patches are welcome to make it better (it was
totally broken before my changes). Failing that, this will remain a
feature request, I'm afraid.
> However, the Elisp manual, node `Size Parameters', is incorrect in
> saying that either `maximized' or `fullboth' does not have
> window-manager decorations.
That's correct only for some window managers, certainly not on
Windows.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-12 21:25 ` Eli Zaretskii
@ 2013-03-12 21:59 ` Drew Adams
2013-03-15 8:30 ` Eli Zaretskii
2013-03-12 22:38 ` Drew Adams
1 sibling, 1 reply; 21+ messages in thread
From: Drew Adams @ 2013-03-12 21:59 UTC (permalink / raw)
To: 'Eli Zaretskii'; +Cc: 13935
> > However, the Elisp manual, node `Size Parameters', is incorrect in
> > saying that either `maximized' or `fullboth' does not have
> > window-manager decorations.
>
> That's correct only for some window managers, certainly not on
> Windows.
The doc should mention this, in that case. Thx.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-12 21:25 ` Eli Zaretskii
2013-03-12 21:59 ` Drew Adams
@ 2013-03-12 22:38 ` Drew Adams
1 sibling, 0 replies; 21+ messages in thread
From: Drew Adams @ 2013-03-12 22:38 UTC (permalink / raw)
To: 'Eli Zaretskii'; +Cc: 13935
> > The frame is not wide enough - about a centimeter too narrow.
>
> That is the best I could do (on my system, the difference is much less
> than 1 cm, FWIW). Patches are welcome to make it better (it was
> totally broken before my changes). Failing that, this will remain a
> feature request, I'm afraid.
Yes, it is less than a centimeter for me also.
It appears to be close to 0.5 cm.
Perhaps the code here will help. I think it DTRT, and it has been used for a
few years by others as well.
http://www.emacswiki.org/emacs-en/download/frame-cmds.el
See command `maximize-frame'. You can ignore the part that reduces the height
to allow for a separate minibuffer frame.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-12 21:59 ` Drew Adams
@ 2013-03-15 8:30 ` Eli Zaretskii
2013-03-15 9:24 ` Dani Moncayo
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Eli Zaretskii @ 2013-03-15 8:30 UTC (permalink / raw)
To: Drew Adams, Jan Djärv; +Cc: 13935
> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <13935@debbugs.gnu.org>
> Date: Tue, 12 Mar 2013 14:59:54 -0700
>
> > > However, the Elisp manual, node `Size Parameters', is incorrect in
> > > saying that either `maximized' or `fullboth' does not have
> > > window-manager decorations.
> >
> > That's correct only for some window managers, certainly not on
> > Windows.
>
> The doc should mention this, in that case. Thx.
I'd like to change the manual text to say the following (only the last
sentence was modified). Can someone (Jan?) please verify that this is
reasonably correct for all the window managers we support? If not,
what needs to be changed in the wording of the last sentence?
Specify that width, height or both shall be maximized. The value
@code{fullwidth} specifies that width shall be as wide as possible.
The value @code{fullheight} specifies that height shall be as tall as
possible. The value @code{fullboth} specifies that both the width and
the height shall be set to the size of the screen. The value
@code{maximized} specifies that the frame shall be maximized. The
difference between @code{maximized} and @code{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.
Thanks.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-15 8:30 ` Eli Zaretskii
@ 2013-03-15 9:24 ` Dani Moncayo
2013-03-15 10:12 ` Eli Zaretskii
2013-03-15 15:17 ` Drew Adams
2013-03-15 15:15 ` Drew Adams
2013-03-23 9:34 ` Eli Zaretskii
2 siblings, 2 replies; 21+ messages in thread
From: Dani Moncayo @ 2013-03-15 9:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13935
Hello Eli,
On a related note, I've just realized that the current trunk version
of Emacs (the MS-Windows port) bounds F11 to one command called
`toggle-frame-fullscreen' (which is supposed to do what its name
suggests).
But I've just tested it in a Windows 7 system (emacs -Q) and it
doesn't work well:
* The first time I type F11 (to toggle fullscreen "on"), I get [1].
IIUC, the menu bar, tool bar, emacs window (with its modeline) and
echo area should take the whole screen, but as you can see, that is
not what is happening.
* The second time I type F11 (to restore the normal size), I get [2].
The frame should be restored to its original size and position, but as
you can see, that doesn't happen either (the original position of the
emacs frame wasn't that).
--- Footnotes -----
[1] https://www.dropbox.com/s/3f3x5ulecwqa1jy/Capture1.PNG
[2] https://www.dropbox.com/s/9gz3a6lzdrsf6xs/Capture2.PNG
--
Dani Moncayo
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-15 9:24 ` Dani Moncayo
@ 2013-03-15 10:12 ` Eli Zaretskii
2013-03-15 10:26 ` Dani Moncayo
` (2 more replies)
2013-03-15 15:17 ` Drew Adams
1 sibling, 3 replies; 21+ messages in thread
From: Eli Zaretskii @ 2013-03-15 10:12 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 13935
> Date: Fri, 15 Mar 2013 10:24:57 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Drew Adams <drew.adams@oracle.com>, Jan Djärv <jan.h.d@swipnet.se>,
> 13935@debbugs.gnu.org
>
> On a related note, I've just realized that the current trunk version
> of Emacs (the MS-Windows port) bounds F11 to one command called
> `toggle-frame-fullscreen' (which is supposed to do what its name
> suggests).
> But I've just tested it in a Windows 7 system (emacs -Q) and it
> doesn't work well:
> * The first time I type F11 (to toggle fullscreen "on"), I get [1].
> IIUC, the menu bar, tool bar, emacs window (with its modeline) and
> echo area should take the whole screen, but as you can see, that is
> not what is happening.
This was because the 'fullboth' terminology is confusing and tricked
me into thinking that 'fullboth' value of the 'fullscreen' frame
parameter means 'fullwidth' and 'fullheight' together. But in fact,
'maximized' is 'fullwidth' and 'fullheight' together, while 'fullboth'
means the same as 'fullscreen'. Confusing.
This is now fixed in revision 112048 on the trunk.
> * The second time I type F11 (to restore the normal size), I get [2].
> The frame should be restored to its original size and position, but as
> you can see, that doesn't happen either (the original position of the
> emacs frame wasn't that).
This feature is not supported in the Windows build, because I couldn't
find a way of doing that. (There's a FIXME in w32fullscreen_hook to
that effect.) Patches to fix this are welcome.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-15 10:12 ` Eli Zaretskii
@ 2013-03-15 10:26 ` Dani Moncayo
2013-03-15 13:07 ` Stefan Monnier
2013-03-15 12:00 ` Jan Djärv
2013-03-15 15:17 ` Drew Adams
2 siblings, 1 reply; 21+ messages in thread
From: Dani Moncayo @ 2013-03-15 10:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13935
>> On a related note, I've just realized that the current trunk version
>> of Emacs (the MS-Windows port) bounds F11 to one command called
>> `toggle-frame-fullscreen' (which is supposed to do what its name
>> suggests).
>> But I've just tested it in a Windows 7 system (emacs -Q) and it
>> doesn't work well:
>> * The first time I type F11 (to toggle fullscreen "on"), I get [1].
>> IIUC, the menu bar, tool bar, emacs window (with its modeline) and
>> echo area should take the whole screen, but as you can see, that is
>> not what is happening.
>
> This was because the 'fullboth' terminology is confusing and tricked
> me into thinking that 'fullboth' value of the 'fullscreen' frame
> parameter means 'fullwidth' and 'fullheight' together. But in fact,
> 'maximized' is 'fullwidth' and 'fullheight' together, while 'fullboth'
> means the same as 'fullscreen'. Confusing.
Yes, I also think it's a pretty confusing and counter-intuitive terminology.
--
Dani Moncayo
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-15 10:12 ` Eli Zaretskii
2013-03-15 10:26 ` Dani Moncayo
@ 2013-03-15 12:00 ` Jan Djärv
2013-03-15 13:53 ` Eli Zaretskii
2013-03-15 15:17 ` Drew Adams
2 siblings, 1 reply; 21+ messages in thread
From: Jan Djärv @ 2013-03-15 12:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13935@debbugs.gnu.org
Hello.
15 mar 2013 kl. 11:12 skrev Eli Zaretskii <eliz@gnu.org>:
> This was because the 'fullboth' terminology is confusing and tricked
> me into thinking that 'fullboth' value of the 'fullscreen' frame
> parameter means 'fullwidth' and 'fullheight' together. But in fact,
> 'maximized' is 'fullwidth' and 'fullheight' together, while 'fullboth'
> means the same as 'fullscreen'. Confusing.
>
In early versions of the EWMH-specification, there was no fullscreen. So when both maximize_width an maximize_height where set, windowmanagers did not know if to do fullscreen or maximized. I guess I used a WM that did fullscreen when I wrote this.
Jan D.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-15 10:26 ` Dani Moncayo
@ 2013-03-15 13:07 ` Stefan Monnier
2013-03-15 13:48 ` Eli Zaretskii
0 siblings, 1 reply; 21+ messages in thread
From: Stefan Monnier @ 2013-03-15 13:07 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 13935
> Yes, I also think it's a pretty confusing and counter-intuitive terminology.
See also bug#10670
Stefan
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-15 13:07 ` Stefan Monnier
@ 2013-03-15 13:48 ` Eli Zaretskii
2013-03-15 17:54 ` Stefan Monnier
0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2013-03-15 13:48 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 13935
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>, 13935@debbugs.gnu.org
> Date: Fri, 15 Mar 2013 09:07:20 -0400
>
> > Yes, I also think it's a pretty confusing and counter-intuitive terminology.
>
> See also bug#10670
That one talks about the _name_ of the parameter; I was talking about
the _values_ (and implicitly also about their reflections in the C
code).
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-15 12:00 ` Jan Djärv
@ 2013-03-15 13:53 ` Eli Zaretskii
2013-03-15 18:32 ` Jan Djärv
0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2013-03-15 13:53 UTC (permalink / raw)
To: Jan Djärv; +Cc: 13935
> Cc: Dani Moncayo <dmoncayo@gmail.com>,
> "drew.adams@oracle.com" <drew.adams@oracle.com>,
> "13935@debbugs.gnu.org" <13935@debbugs.gnu.org>
> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Fri, 15 Mar 2013 13:00:27 +0100
>
> > This was because the 'fullboth' terminology is confusing and tricked
> > me into thinking that 'fullboth' value of the 'fullscreen' frame
> > parameter means 'fullwidth' and 'fullheight' together. But in fact,
> > 'maximized' is 'fullwidth' and 'fullheight' together, while 'fullboth'
> > means the same as 'fullscreen'. Confusing.
> >
>
> In early versions of the EWMH-specification, there was no fullscreen. So when both maximize_width an maximize_height where set, windowmanagers did not know if to do fullscreen or maximized. I guess I used a WM that did fullscreen when I wrote this.
My problem was not with how we tell the WM to go full-screen. My
problem was with the Lisp symbols used for the possible values of this
frame parameter, and with their equivalent C enumeration values.
E.g., this code in frame.c:
if (NILP (new_value))
f->want_fullscreen = FULLSCREEN_NONE;
else if (EQ (new_value, Qfullboth) || EQ (new_value, Qfullscreen))
f->want_fullscreen = FULLSCREEN_BOTH;
else if (EQ (new_value, Qfullwidth))
f->want_fullscreen = FULLSCREEN_WIDTH;
else if (EQ (new_value, Qfullheight))
f->want_fullscreen = FULLSCREEN_HEIGHT;
else if (EQ (new_value, Qmaximized))
f->want_fullscreen = FULLSCREEN_MAXIMIZED;
FULLSCREEN_BOTH is clearly hinting that it is both FULLSCREEN_HEIGHT
and FULLSCREEN_WIDTH, while FULLSCREEN_MAXIMIZED is the odd one out.
But in fact, it's FULLSCREEN_BOTH that's the odd one out, and on the
Lisp level 'fullboth' and 'fullscreen' are synonyms. That's what
confused me: the semantics of these values, and their counter-mnemonic
nature.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-15 8:30 ` Eli Zaretskii
2013-03-15 9:24 ` Dani Moncayo
@ 2013-03-15 15:15 ` Drew Adams
2013-03-15 15:41 ` Eli Zaretskii
2013-03-23 9:34 ` Eli Zaretskii
2 siblings, 1 reply; 21+ messages in thread
From: Drew Adams @ 2013-03-15 15:15 UTC (permalink / raw)
To: 'Eli Zaretskii', 'Jan Djärv'; +Cc: 13935
> > > That's correct only for some window managers, certainly not on
> > > Windows.
> >
> > The doc should mention this, in that case. Thx.
>
> I'd like to change the manual text to say the following (only the last
> sentence was modified). Can someone (Jan?) please verify that this is
> reasonably correct for all the window managers we support? If not,
> what needs to be changed in the wording of the last sentence?
>
> Specify that width, height or both shall be maximized. The value
> @code{fullwidth} specifies that width shall be as wide as possible.
> The value @code{fullheight} specifies that height shall be
> as tall as
> possible. The value @code{fullboth} specifies that both
> the width and
> the height shall be set to the size of the screen. The value
> @code{maximized} specifies that the frame shall be maximized. The
> difference between @code{maximized} and @code{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.
1. Your proposed text is OK by me.
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". And on Windows fullboth is not "the size of the screen"
(because of the task bar and the width gap mentioned).
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'.)
4. In spite of all that, if you want to close the bug after applying your
proposed manual text, it's OK by me.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-15 9:24 ` Dani Moncayo
2013-03-15 10:12 ` Eli Zaretskii
@ 2013-03-15 15:17 ` Drew Adams
1 sibling, 0 replies; 21+ messages in thread
From: Drew Adams @ 2013-03-15 15:17 UTC (permalink / raw)
To: 'Dani Moncayo', 'Eli Zaretskii'; +Cc: 13935
> On a related note, I've just realized that the current trunk version
> of Emacs (the MS-Windows port) bounds F11 to one command called
> `toggle-frame-fullscreen' (which is supposed to do what its name
> suggests).
This useful key should never have been wasted on such a toggle, IMO. Emacs is
stooping to lowest(-somewhat)-common-denominator by doing this. Let users who
really want Emacs to "conform" to such a "convention" bind the key themselves.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-15 10:12 ` Eli Zaretskii
2013-03-15 10:26 ` Dani Moncayo
2013-03-15 12:00 ` Jan Djärv
@ 2013-03-15 15:17 ` Drew Adams
2 siblings, 0 replies; 21+ messages in thread
From: Drew Adams @ 2013-03-15 15:17 UTC (permalink / raw)
To: 'Eli Zaretskii', 'Dani Moncayo'; +Cc: 13935
> > * The second time I type F11 (to restore the normal size),
> I get [2].
> > The frame should be restored to its original size and
> position, but as
> > you can see, that doesn't happen either (the original
> position of the
> > emacs frame wasn't that).
>
> This feature is not supported in the Windows build, because I couldn't
> find a way of doing that. (There's a FIXME in w32fullscreen_hook to
> that effect.) Patches to fix this are welcome.
FWIW, the frame-cmds.el code also correctly handles restoring size and position.
It does not do window-mgr maximization, however (which I guess requires C
changes?). Its "maximizing" uses the available screen space and does not affect
the `Maximize' button of the window mgr.
(BTW, it also lets you maximize/restore only horizontally or only vertically, if
you want.)
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-15 15:15 ` Drew Adams
@ 2013-03-15 15:41 ` Eli Zaretskii
0 siblings, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2013-03-15 15:41 UTC (permalink / raw)
To: Drew Adams; +Cc: 13935
> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <13935@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-15 13:48 ` Eli Zaretskii
@ 2013-03-15 17:54 ` Stefan Monnier
0 siblings, 0 replies; 21+ messages in thread
From: Stefan Monnier @ 2013-03-15 17:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13935
>> > Yes, I also think it's a pretty confusing and
>> > counter-intuitive terminology.
>> See also bug#10670
> That one talks about the _name_ of the parameter; I was talking about
> the _values_ (and implicitly also about their reflections in the C
> code).
Actually, it also suggests changing the values. And the proposed names
to use as values would match the names used in the C code.
Stefan
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-15 13:53 ` Eli Zaretskii
@ 2013-03-15 18:32 ` Jan Djärv
0 siblings, 0 replies; 21+ messages in thread
From: Jan Djärv @ 2013-03-15 18:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13935@debbugs.gnu.org
Hi.
15 mar 2013 kl. 14:53 skrev Eli Zaretskii <eliz@gnu.org>:
> FULLSCREEN_BOTH is clearly hinting that it is both FULLSCREEN_HEIGHT
> and FULLSCREEN_WIDTH, while FULLSCREEN_MAXIMIZED is the odd one out.
As I said, when this was done, width and height implied both for some WM. The C values are a reflection of this.
Jan D.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-15 8:30 ` Eli Zaretskii
2013-03-15 9:24 ` Dani Moncayo
2013-03-15 15:15 ` Drew Adams
@ 2013-03-23 9:34 ` Eli Zaretskii
2013-03-23 15:11 ` Drew Adams
2 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2013-03-23 9:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13935-done
> Date: Fri, 15 Mar 2013 10:30:40 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 13935@debbugs.gnu.org
>
> I'd like to change the manual text to say the following (only the last
> sentence was modified). Can someone (Jan?) please verify that this is
> reasonably correct for all the window managers we support? If not,
> what needs to be changed in the wording of the last sentence?
>
> Specify that width, height or both shall be maximized. The value
> @code{fullwidth} specifies that width shall be as wide as possible.
> The value @code{fullheight} specifies that height shall be as tall as
> possible. The value @code{fullboth} specifies that both the width and
> the height shall be set to the size of the screen. The value
> @code{maximized} specifies that the frame shall be maximized. The
> difference between @code{maximized} and @code{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.
>
> Thanks.
No comments, so I committed the above as trunk revision 112115, and
I'm closing the bug report.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-23 9:34 ` Eli Zaretskii
@ 2013-03-23 15:11 ` Drew Adams
2013-03-23 15:39 ` Eli Zaretskii
0 siblings, 1 reply; 21+ messages in thread
From: Drew Adams @ 2013-03-23 15:11 UTC (permalink / raw)
To: 'Eli Zaretskii'; +Cc: 13935-done
> No comments,
FWIW, I did provide comments.
> so I committed the above as trunk revision 112115, and
> I'm closing the bug report.
OK by me, thanks.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least
2013-03-23 15:11 ` Drew Adams
@ 2013-03-23 15:39 ` Eli Zaretskii
0 siblings, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2013-03-23 15:39 UTC (permalink / raw)
To: Drew Adams; +Cc: 13935
> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <jan.h.d@swipnet.se>, <13935-done@debbugs.gnu.org>
> Date: Sat, 23 Mar 2013 08:11:06 -0700
>
> > No comments,
>
> FWIW, I did provide comments.
Sorry, I meant no comments about correctness of the text for X11.
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2013-03-23 15:39 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-12 20:44 bug#13935: 24.3.50; `fullscreen' frame parameter is wrong, on MS Windows at least Drew Adams
2013-03-12 21:25 ` Eli Zaretskii
2013-03-12 21:59 ` Drew Adams
2013-03-15 8:30 ` Eli Zaretskii
2013-03-15 9:24 ` Dani Moncayo
2013-03-15 10:12 ` Eli Zaretskii
2013-03-15 10:26 ` Dani Moncayo
2013-03-15 13:07 ` Stefan Monnier
2013-03-15 13:48 ` Eli Zaretskii
2013-03-15 17:54 ` Stefan Monnier
2013-03-15 12:00 ` Jan Djärv
2013-03-15 13:53 ` Eli Zaretskii
2013-03-15 18:32 ` Jan Djärv
2013-03-15 15:17 ` Drew Adams
2013-03-15 15:17 ` Drew Adams
2013-03-15 15:15 ` Drew Adams
2013-03-15 15:41 ` Eli Zaretskii
2013-03-23 9:34 ` Eli Zaretskii
2013-03-23 15:11 ` Drew Adams
2013-03-23 15:39 ` Eli Zaretskii
2013-03-12 22:38 ` Drew Adams
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).