From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs Subject: bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame Date: Sat, 3 Oct 2015 08:16:37 +0200 Message-ID: References: <55FFD141.2030405@gmx.at> <5600F763.3020305@gmx.at> <5601211E.3090001@gmx.at> <5608E2AB.7010407@gmx.at> <560A3C87.3060802@gmx.at> <560C3090.6000902@gmx.at> <560E4246.1080306@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11431b660d70c005212d39c9 X-Trace: ger.gmane.org 1443853041 12417 80.91.229.3 (3 Oct 2015 06:17:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 3 Oct 2015 06:17:21 +0000 (UTC) Cc: Keith David Bershatsky , 21415@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 03 08:17:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZiG86-0003jm-TL for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Oct 2015 08:17:11 +0200 Original-Received: from localhost ([::1]:37121 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiG86-00071D-8d for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Oct 2015 02:17:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiG82-00070y-9B for bug-gnu-emacs@gnu.org; Sat, 03 Oct 2015 02:17:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZiG7y-0001LV-Oc for bug-gnu-emacs@gnu.org; Sat, 03 Oct 2015 02:17:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35488) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiG7y-0001LN-Lb for bug-gnu-emacs@gnu.org; Sat, 03 Oct 2015 02:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZiG7y-0007ay-9w for bug-gnu-emacs@gnu.org; Sat, 03 Oct 2015 02:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Oct 2015 06:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21415 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21415-submit@debbugs.gnu.org id=B21415.144385300229159 (code B ref 21415); Sat, 03 Oct 2015 06:17:02 +0000 Original-Received: (at 21415) by debbugs.gnu.org; 3 Oct 2015 06:16:42 +0000 Original-Received: from localhost ([127.0.0.1]:52692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiG7d-0007aE-Ct for submit@debbugs.gnu.org; Sat, 03 Oct 2015 02:16:42 -0400 Original-Received: from mail-vk0-f46.google.com ([209.85.213.46]:35288) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiG7a-0007a4-L7 for 21415@debbugs.gnu.org; Sat, 03 Oct 2015 02:16:39 -0400 Original-Received: by vkao3 with SMTP id o3so71601443vka.2 for <21415@debbugs.gnu.org>; Fri, 02 Oct 2015 23:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CIMtjD5Z8lWoZXJU9xObrcsP2V9zuDItPieeUlfHMBo=; b=GafSircrOOCH3a1dn60DJn7Wv/FP7oCZLB785ziaZw3sZkaR6VajU0lN9uKA/1Tixe nYbUWQt9MIrUQp8mJqVNB+fMtO7tdtU3CORWiIFof9iDGPJAut6NqgIBA1mH9hpvJpxX vg1ynUGQJyCYmRBESz45IUTWe0xIEOcQIcUu9zl5swZRtZqhg6I9KlPPLgCfCtj39lSf 1llnWOWpJdwECHsl7byIWU8DrtjPe4Id+RrRjqnXr2xN/5BgEnIAPg+InLQmA0J/d030 A+wbIA1HiDFmh6ZW3aPx3hsv7uIKQwRzb+YITYza99epT0xwzRBD0eMNnUmHYQm3KtmR +DHw== X-Received: by 10.31.170.68 with SMTP id t65mr11254537vke.31.1443852997978; Fri, 02 Oct 2015 23:16:37 -0700 (PDT) Original-Received: by 10.31.139.21 with HTTP; Fri, 2 Oct 2015 23:16:37 -0700 (PDT) In-Reply-To: <560E4246.1080306@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:107238 Archived-At: --001a11431b660d70c005212d39c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 usi= ng > > the user interface, it's frame doesn't cover the entire screen (the sam= e > > four pixels as in Emacs). To cover the entire screen, another command > must > > be issued which cycles through maximized, maximized with hidden menu ba= r, > > 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 =E2=80=98toggle-frame-maximized=E2=80=99 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 --001a11431b660d70c005212d39c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!

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

No, the button does not change in any way when zooming.
<= br>
The button is typically always plain green. When hovering abo= ve 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 op= eration 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 t= hose versions, the green button always contained a "+" when hover= ing above it.


> FullScreen is a totally different animal with a special sidewa= ys animation,
> gives the application exclusive use of the screen, and blanks out othe= r
> monitors.

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

It's always use the ful= l screen, as far as I can tell.

In fact, when in f= ullscreen 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 ha= nd, I
> compared with another application (LightRoom). When it is maximized us= ing
> 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 b= ar,
> and normal.

 I'm afraid that I don't yet understand that "cycling".=C2= =A0 Do you mean that
pushing that button (which I presume is the "user interface") rep= eatedly
cycles through these three states?

Yes, it = does.

I think this behaviour is fine.
=C2=A0
=C2=A0In that case there'= s still the
question whether =E2=80=98toggle-frame-maximized=E2=80=99 should hide the m= enu bar.

I would say no.

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

=
I see no reason to change this.


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

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


All in all, the Emacs system works well. T= he only problem is that a maximized window doesn't cover the entire scr= een. 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 animati= on, then do an extra resize after it's done.

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

/ Anders
--001a11431b660d70c005212d39c9--