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: Mon, 28 Sep 2015 23:35:50 +0200 Message-ID: References: <55FFD141.2030405@gmx.at> <5600F763.3020305@gmx.at> <5601211E.3090001@gmx.at> <5608E2AB.7010407@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113da7c833efb20520d57b64 X-Trace: ger.gmane.org 1443490511 24149 80.91.229.3 (29 Sep 2015 01:35:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Sep 2015 01:35:11 +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 Tue Sep 29 03:35:03 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 1Zgjos-0007eY-OR for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Sep 2015 03:35:03 +0200 Original-Received: from localhost ([::1]:43956 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgjor-0008Ak-Tb for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Sep 2015 21:35:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51953) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgg5f-0007jp-Ta for bug-gnu-emacs@gnu.org; Mon, 28 Sep 2015 17:36:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zgg5a-0003hj-KY for bug-gnu-emacs@gnu.org; Mon, 28 Sep 2015 17:36:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58022) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgg5a-0003hb-Es for bug-gnu-emacs@gnu.org; Mon, 28 Sep 2015 17:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zgg5a-0003OK-A0 for bug-gnu-emacs@gnu.org; Mon, 28 Sep 2015 17:36: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: Mon, 28 Sep 2015 21:36: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.144347615413022 (code B ref 21415); Mon, 28 Sep 2015 21:36:02 +0000 Original-Received: (at 21415) by debbugs.gnu.org; 28 Sep 2015 21:35:54 +0000 Original-Received: from localhost ([127.0.0.1]:46993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zgg5R-0003Nx-9M for submit@debbugs.gnu.org; Mon, 28 Sep 2015 17:35:54 -0400 Original-Received: from mail-vk0-f47.google.com ([209.85.213.47]:35649) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zgg5P-0003Nn-As for 21415@debbugs.gnu.org; Mon, 28 Sep 2015 17:35:52 -0400 Original-Received: by vkao3 with SMTP id o3so91640634vka.2 for <21415@debbugs.gnu.org>; Mon, 28 Sep 2015 14:35:50 -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=xjS0bLLU+Pb0KH6TtR+szHFyd0V4bnCSB3DXB2RLVn0=; b=Cp5gV4eVYruuSR/mxPt5cbGsXJpfBCkvsQRSdJbBQUoiROWwTHa9sMtf5DDUJ3tPtR glc8Of0Lp4Nx1GFHTRIHHi1SOe6ousQaaXOUUjlRaNn6l0589yHf031ib0Wb1VpG2LnW HRjNWb2i08ynDRzK8XDs7oFZ1y1cwX+xSNZQOLsefQr+AQGWRuWNP1Vbz0KipUHOIouL DmS3/QANAe/pgqHS3gnMII/WUVx9E839e1an+fBSTZvISb39FeyVsROkOijW3U4tz/hl nEHFV/GkphOm1OLYmOT8k7LH6GcsQhlGCvlYhtm1u6EmnRQozVFT/Cj3RVuJ2avmHZbD YHEA== X-Received: by 10.31.0.215 with SMTP id 206mr13936713vka.105.1443476150674; Mon, 28 Sep 2015 14:35:50 -0700 (PDT) Original-Received: by 10.31.139.21 with HTTP; Mon, 28 Sep 2015 14:35:50 -0700 (PDT) In-Reply-To: <5608E2AB.7010407@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:107028 Archived-At: --001a113da7c833efb20520d57b64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! > Makes sense. Pushed as 73b0901..e55460e to master. Thanks! > To see the difference, run Emacs -Q and evaluate the following. After the > > patch is applied, the frame is no longer moves down. > > > > (progn > > (setq frame-resize-pixelwise t) > > (toggle-frame-maximized)) > > > > Unfortunately, the frame still doesn't cover the entire screen. > > Usually it shouldn't, for maximizing. The problem as far as I > understand is that NS doesn't have the concept of a "maximized" frame. > In earlier OS X versions, the green button was designed to make the window large enough to accommodate the current document. In many applications, this meant that the window grew to it's maximum hight, minus those missing four pixels. In newer versions, the green button makes the application enter fullscreen mode. Internally, however, internally, it's still possible to issue either "toggleFullScreen" or "performZoom". When you do what, in Chrome? Try maximizing the Chrome window? How do > you do that? If I manually drag the Chrome window to its largest size, I can make it stretch the entire width, but there will be four pixels missing at the bottom. Also, if I hit the green button in older OS X versions, the same four pixels are missing from the bottom. > We have the concept of a "workarea" as it's returned by > =E2=80=98display-monitor-attributes-list=E2=80=99. On all systems I know= of, a > "maximized" frame occupies the full workarea, a "fullwidth" frame the > full width of the workarea and a "fullheight" frame the full height of > the workarea. (I have no idea how these concepts expand to multiple > monitors though.) How do the four unused pixels relate to your > workarea? The function returns the following: (((name . "SyncMaster") (geometry 0 0 1600 1200) (workarea 0 23 1600 1173) (mm-size 432 324) (frames #) (source . "NS")) ((name . "SyncMaster") (geometry 1600 0 1600 1200) (workarea 1600 0 1600 1200) (mm-size 432 324) (frames) (source . "NS"))) Interestingly, the workarea of the primary screen is missing four pixels (1200 - 1173 - 34) =3D 4. However, the workarea of the secondary monitor does not. When executing `toggle-frame-maximized' on the secondary frame (with `frame-resize-pixelwise' set to t), the frame is placed at the bottom left corner (which is good), but there are four pixles missing at the TOP of the screen. (I haven't investigated why, though.) > In the Info documentation to the `fullscreen' frame parameter, there are > > two values missing: `nil' and `fullscreen'. The former indicates that t= he > > frame is in non-maximized state > > nil means "neither of =E2=80=98maximized=E2=80=99, =E2=80=98fullwidth=E2= =80=99, =E2=80=98fullheight=E2=80=99 or > =E2=80=98fullboth=E2=80=99". Yes, I guessed so -- but it needs to be documented, right? > Interestingly, the function `toggle-frame-fullscreen' seems to > > use this undocumented parameter value. > > It accepts it IIUC but it does not store it. Or what do you mean? > My mistake -- I was looking at the 24.5 source. There, the `fullscreen' property was set to `fullscreen'. It has been fixed in the Emacs 25 source. > (In addition, there are some control > > characters showing on the first line.) > > Please elaborate. In the "info" documentation, the first line looks like the following, where the backslash-numbers represent a single character. I guess this is some kind of encoding issue... This parameter specifies whether to maximize the frame\342\200\231s width, > On a side note, the NSTRACE rewrite is coming along nicely (it really > > helped in tracking down this problem) but it's not yet ready for releas= e. > > Fine. Can you please get yourself write access to the git repository so > you can install it when it's ready? I feel some unease installing > larger changes on systems where I cannot check the consequences myself > immediately. I fully understand. Who should I talk to to get write access? (The last time I was doing any serious work on Emacs, Jan Dj=C3=A4rv did the checkins= , but that was before he resigned.) / Anders --001a113da7c833efb20520d57b64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!
=C2=A0
Makes sense.=C2=A0 Pushed as 73= b0901..e55460e to master.

Thanks!


> To see the= difference, run Emacs -Q and evaluate the following. After the
> patch is applied, the frame is no longer moves down.
>
>=C2=A0 =C2=A0 =C2=A0 (progn
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (setq frame-resize-pixelwise t)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (toggle-frame-maximized))
>
> Unfortunately, the frame still doesn't cover the entire screen.
Usually it shouldn't, for maximizing.=C2=A0 The problem as far as I
understand is that NS doesn't have the concept of a "maximized&quo= t; frame.

In ea= rlier OS X versions, the green button was designed to make the window large= enough to accommodate the current document. In many applications, this mea= nt that the window grew to it's maximum hight, minus those missing four= pixels.

In newer versions, the green button makes= the application enter fullscreen mode.

Internally= , however, internally, it's still possible to issue either "toggle= FullScreen" or "performZoom".


<= /div>
When you do what, in Chrome?=C2=A0 Try maximizing the Chrome wind= ow?=C2=A0 How do
you do that?

If I manually drag the Chrome = window to its largest size, I can make it stretch the entire width, but the= re will be four pixels missing at the bottom. Also, if I hit the green butt= on in older OS X versions, the same four pixels are missing from the bottom= .
=C2=A0
We have the concept of a "workarea" as it's returned by
=E2=80=98display-monitor-attributes-list=E2=80=99.=C2=A0 On all systems I k= now of, a
"maximized" frame occupies the full workarea, a "fullwidth&q= uot; frame the
full width of the workarea and a "fullheight" frame the full heig= ht of
the workarea. (I have no idea how these concepts expand to multiple
monitors though.)=C2=A0 How do the four unused pixels relate to your
workarea?

The function returns the followin= g:

(((name . "SyncMaster")
=C2=A0 (geometry 0 0 1600 1200)
=C2=A0 (workarea 0 23 1600 1173= )
=C2=A0 (mm-size 432 324)
=C2=A0 (frames #<frame *s= cratch* 0x101099630>)
=C2=A0 (source . "NS"))
<= div>=C2=A0((name . "SyncMaster")
=C2=A0 (geometry 1600 = 0 1600 1200)
=C2=A0 (workarea 1600 0 1600 1200)
=C2=A0 = (mm-size 432 324)
=C2=A0 (frames)
=C2=A0 (source . &quo= t;NS")))

Interestingly, the workarea of= the primary screen is missing four pixels (1200 - 1173 - 34) =3D 4.
<= div>
However, the workarea of the secondary monitor does not.= When executing `toggle-frame-maximized' on the secondary frame (with `= frame-resize-pixelwise' set to t), the frame is placed at the bottom le= ft corner (which is good), but there are four pixles missing at the TOP of = the screen. (I haven't investigated why, though.)

<= div>
> In the Info documentat= ion to the `fullscreen' frame parameter, there are
> two values missing: `nil' and `fullscreen'. The former indicat= es that the
> frame is in non-maximized state

 nil means "neither of =E2=80=98maximized=E2=80=99, =E2=80=98fullwidth= =E2=80=99, =E2=80=98fullheight=E2=80=99 or
=E2=80=98fullboth=E2=80=99".

Yes, I gu= essed so -- but it needs to be documented, right?

=
> Interestingly, the functio= n `toggle-frame-fullscreen' seems to
> use this undocumented parameter value.

 It accepts it IIUC but it does not store it.=C2=A0 Or what do you mean?
=

My mistake -- I was looking at the 24.5 so= urce. There, the `fullscreen' property was set to `fullscreen'. It = has been fixed in the Emacs 25 source.


<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">> (In addition, there are some control<= br> > characters showing on the first line.)

 Please elaborate.

In the "info" d= ocumentation, the first line looks like the following, where the backslash-= numbers represent a single character. I guess this is some kind of encoding= issue...

=C2=A0 =C2=A0 =C2=A0This parameter speci= fies whether to maximize the frame\342\200\231s width,
=C2=A0=

> On a side note,= the NSTRACE rewrite is coming along nicely (it really
> helped in tracking down this problem) but it's not yet ready for r= elease.

 Fine.=C2=A0 Can you please get yourself write access to the git repository = so
you can install it when it's ready?=C2=A0 I feel some unease installing=
larger changes on systems where I cannot check the consequences myself
immediately.

I fully understand. Who should= I talk to to get write access? (The last time I was doing any serious work= on Emacs, Jan Dj=C3=A4rv did the checkins, but that was before he resigned= .)
=C2=A0
/ Anders

--001a113da7c833efb20520d57b64--