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

Previous Next

Full log

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

From: Anders Lindgren <andlind <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
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: Sat, 3 Oct 2015 08:16:37 +0200

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Previous Next

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