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: Wed, 30 Sep 2015 23:29:56 +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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1140feb6c72d7b0520fda1e2 X-Trace: ger.gmane.org 1443698223 10650 80.91.229.3 (1 Oct 2015 11:17:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 11:17:03 +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 Thu Oct 01 13:16:55 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 1Zhbr5-0008UL-28 for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Oct 2015 13:16:55 +0200 Original-Received: from localhost ([::1]:48254 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhbr4-0005Zy-Ip for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Oct 2015 07:16:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhOwz-0006YQ-TC for bug-gnu-emacs@gnu.org; Wed, 30 Sep 2015 17:30:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhOww-0000p4-Lj for bug-gnu-emacs@gnu.org; Wed, 30 Sep 2015 17:30:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhOww-0000nr-AD for bug-gnu-emacs@gnu.org; Wed, 30 Sep 2015 17:30:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZhOwv-0007iZ-Nx for bug-gnu-emacs@gnu.org; Wed, 30 Sep 2015 17:30:05 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Sep 2015 21:30:05 +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.144364859929631 (code B ref 21415); Wed, 30 Sep 2015 21:30:05 +0000 Original-Received: (at 21415) by debbugs.gnu.org; 30 Sep 2015 21:29:59 +0000 Original-Received: from localhost ([127.0.0.1]:49641 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZhOwo-0007hq-I4 for submit@debbugs.gnu.org; Wed, 30 Sep 2015 17:29:59 -0400 Original-Received: from mail-yk0-f169.google.com ([209.85.160.169]:34225) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZhOwn-0007hh-2L for 21415@debbugs.gnu.org; Wed, 30 Sep 2015 17:29:57 -0400 Original-Received: by ykdg206 with SMTP id g206so57996470ykd.1 for <21415@debbugs.gnu.org>; Wed, 30 Sep 2015 14:29:56 -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=j0kdYRrwvB9+nxrwBKa3OvmF2WHatB+8Wiwo8pqotiw=; b=j/fcnXYm7BW5AtDCDn/R/1C7ciot3KyWibwBzLzIn5wkM2gY735sHYvG30EjCpR7QK SoiKIKsS7WcxmEjYp3LCOT1s3/57AWhRuOe9Jyo7LEzsQ9X1+5TIxrAkB3rJ4/GprKh/ GlhrAljf7bmy7QdSbIe0tBqpRfaqRjZwmLPvUkWx4L/EEItzPhaXaZOkHC218M+GfW/M ssa2EQcTUieGYGmdW6PyiWSct+58BnxyyoStVl6zBzR+aBZWG+IEZ/oN1PlOZCf8PGOn kPKR0M5jRPOhunza9YQ9mVXswOWpAJ3JBgU+xTrRB42i9/JrQ89f0gIaKBP4ZPTdTe4q bRxg== X-Received: by 10.31.147.129 with SMTP id v123mr4643778vkd.23.1443648596550; Wed, 30 Sep 2015 14:29:56 -0700 (PDT) Original-Received: by 10.31.139.21 with HTTP; Wed, 30 Sep 2015 14:29:56 -0700 (PDT) In-Reply-To: <560C3090.6000902@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:107118 Archived-At: --001a1140feb6c72d7b0520fda1e2 Content-Type: text/plain; charset=UTF-8 > > IIUC the Mac menu bar is what other systems call a task bar. In that > case, a maximized frame should cover everything but the menu bar and a > fullboth frame should cover the entire screen. Now if I understand you > correctly, Mac doesn't distinguish the various "zoomed" states - a > fullheight frame is just as "zoomed" as a fullscreen or maximized one. 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. FullScreen is a totally different animal with a special sideways animation, gives the application exclusive use of the screen, and blanks out other monitors. 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). 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. 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. / Anders --001a1140feb6c72d7b0520fda1e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IIUC the Mac menu bar is what other systems call a task bar.= =C2=A0 In that
case, a maximized frame should cover everything but the menu bar and a
fullboth frame should cover the entire screen.=C2=A0 Now if I understand yo= u
correctly, Mac doesn't distinguish the various "zoomed" state= s - a
fullheight frame is just as "zoomed" as a fullscreen or maximized= one.

Zooming and fullscreen are two differ= ent concepts. Zooming is a generic system, and it's up to the applicati= on to decide what to do. When initialized using the user interface, Emacs s= teps through full-height, maximized, and original size. When the frame `ful= lscreen' property is updated, the correct state is set immediately. OS = X is simply informed of the end size and placement and resized the frame us= ing a resizing animation.

FullScreen is a totally = different animal with a special sideways animation, gives the application e= xclusive use of the screen, and blanks out other monitors.

Today, I did try a little experiment by modifying=C2=A0`windowWill= UseStandardFrame:' 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 p= ixels, 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 leftmo= st pixels. Also, if the Dock is not in auto-hide mode, OS X will restrict z= oom so that the dock isn't covered at all (i.e. some 20 or 30 pixels).<= /div>

It would be relatively easy to modify the code so = that setting a frame parameter would set the frame size without using the z= oom system. However, it would make maximizing the frame using the user inte= rface different from `toggle-frame-maximized', which might be undesirab= le. On the other hand, I compared with another application (LightRoom). Whe= n it is maximized using the user interface, it's frame doesn't cove= r the entire screen (the same four pixels as in Emacs). To cover the entire= screen, another command must be issued which cycles through maximized, max= imized with hidden menu bar, and normal.

/ Anders<= /div>

--001a1140feb6c72d7b0520fda1e2--