bug-gnu-emacs
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]