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: Anders Lindgren
Subject: bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame
Date: Sat, 3 Oct 2015 08:16:37 +0200

Hi!

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

No, the button does not change in any way when zooming.

The button is typically always plain green. When hovering above it, it displays the fullscreen version of it (two arrows pointing either inwards or outwards, depending on the fullscreen state). When pressing ALT, the button change to contain a "+" sign, indicating that the operation will be a "zoom". The application will display the "+" sign regardless of whether it's maximized or not.

In earlier versions of OS X, there was no fullscreen mode. In those versions, the green button always contained a "+" when hovering above it.


> 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?

It's always use the full screen, as far as I can tell.

In fact, when in fullscreen mode, the menu bar, tool bar, and title bar are hidden. When the mouse touch the upper part of the screen, they slide in.

As far as I can tell, fullscreen mode work very well.


> 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?

Yes, it does.

I think this behaviour is fine.

 
 In that case there's still the
question whether ‘toggle-frame-maximized’ should hide the menu bar.

I would say no.

Currently, the user can hide the menu bar by setting `ns-auto-hide-menu-bar' to t. If this is set, `toggle-frame-maximized' (and zooming using the user interface) use the entire screen.

I see no reason to change this.


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

Different applications use different states, it was only an example of how another application handle similar situation. I don't think this cycle is the way to go for us.


All in all, the Emacs system works well. The only problem is that a maximized window doesn't cover the entire screen. I have been thinking about two alternatives:

* Replace the zoom code with a custom one that simply sets the correct size. (Hopefully, it's possible to get this to work with the zoom button as well.)
* Call the standard zoom function to get the zoom animation, then do an extra resize after it's done.

Also, one could imagine a new variable `ns-use-native-zoom' if the user would like the normal zoom.

/ Anders

reply via email to

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