GNU bug report logs - #21415
25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: "eliz <at> gnu.org" <eliz <at> gnu.org>, Keith David Bershatsky <esq <at> lawlist.com>,
 21415 <at> debbugs.gnu.org
Subject: Re: bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for
 x-create-frame
Date: Fri, 02 Oct 2015 10:37:26 +0200

> Zooming and fullscreen are two different concepts. Zooming is a generic
> system, and it's up to the application to decide what to do. When
> initialized using the user interface, Emacs steps through full-height,
> maximized, and original size. When the frame `fullscreen' property is
> updated, the correct state is set immediately. OS X is simply informed of
> the end size and placement and resized the frame using a resizing animation.

But is the fact that OS X has responded to our zooming request reflected
in that "button" and if so in which way?

> FullScreen is a totally different animal with a special sideways animation,
> gives the application exclusive use of the screen, and blanks out other
> monitors.

What is the size of such a "FullScreen" screen in relation to the size
of your screen?

> Today, I did try a little experiment by
> modifying `windowWillUseStandardFrame:' to return the full screen size.
> Unfortunately, using this method it doesn't seem possible to make the frame
> use the entire screen -- it appears as though the system restrict the
> requested frame size to what it considers the visible area.
>
> The four pixels, by the way, is related to the position of the "Dock" -- if
> it is placed on the side of the screen, OS X won't use the four leftmost
> pixels. Also, if the Dock is not in auto-hide mode, OS X will restrict zoom
> so that the dock isn't covered at all (i.e. some 20 or 30 pixels).

This makes sense, more or less.

> It would be relatively easy to modify the code so that setting a frame
> parameter would set the frame size without using the zoom system. However,
> it would make maximizing the frame using the user interface different from
> `toggle-frame-maximized', which might be undesirable.

Agreed.

> On the other hand, I
> compared with another application (LightRoom). When it is maximized using
> the user interface, it's frame doesn't cover the entire screen (the same
> four pixels as in Emacs). To cover the entire screen, another command must
> be issued which cycles through maximized, maximized with hidden menu bar,
> and normal.

I'm afraid that I don't yet understand that "cycling".  Do you mean that
pushing that button (which I presume is the "user interface") repeatedly
cycles through these three states?  In that case there's still the
question whether ‘toggle-frame-maximized’ should hide the menu bar.

BTW, you above say "full-height" and "maximized" and here you talk about
"maximized" and "maximized with hidden menu bar".  Which of these
correlate?

martin

Previous Next

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