[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-f
From: |
martin rudalics |
Subject: |
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
bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame, Keith David Bershatsky, 2015/10/08
bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame, Keith David Bershatsky, 2015/10/08