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 19:54:33 +0200 Message-ID: References: <55FFD141.2030405@gmx.at> <5600F763.3020305@gmx.at> <5601211E.3090001@gmx.at> <5608E2AB.7010407@gmx.at> <560A3C87.3060802@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113da7c880f9290520fa9f1b X-Trace: ger.gmane.org 1443685480 402 80.91.229.3 (1 Oct 2015 07:44:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 07:44:40 +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 09:44:33 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 1ZhYXZ-0001QR-23 for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Oct 2015 09:44:33 +0200 Original-Received: from localhost ([::1]:39998 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhYXY-0007Ib-6r for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Oct 2015 03:44:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhLat-0003Sq-Sc for bug-gnu-emacs@gnu.org; Wed, 30 Sep 2015 13:55:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhLao-0005lG-W3 for bug-gnu-emacs@gnu.org; Wed, 30 Sep 2015 13:55:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60539) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhLao-0005l9-Ts for bug-gnu-emacs@gnu.org; Wed, 30 Sep 2015 13:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZhLao-0002dy-Nj for bug-gnu-emacs@gnu.org; Wed, 30 Sep 2015 13:55: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: Wed, 30 Sep 2015 17:55: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.144363567710124 (code B ref 21415); Wed, 30 Sep 2015 17:55:02 +0000 Original-Received: (at 21415) by debbugs.gnu.org; 30 Sep 2015 17:54:37 +0000 Original-Received: from localhost ([127.0.0.1]:49510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZhLaO-0002dE-W6 for submit@debbugs.gnu.org; Wed, 30 Sep 2015 13:54:37 -0400 Original-Received: from mail-vk0-f46.google.com ([209.85.213.46]:32894) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZhLaM-0002d5-7a for 21415@debbugs.gnu.org; Wed, 30 Sep 2015 13:54:35 -0400 Original-Received: by vkgd64 with SMTP id d64so26750977vkg.0 for <21415@debbugs.gnu.org>; Wed, 30 Sep 2015 10:54:33 -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=QHrENVtY4uJuDFUPVU9Q2kLwvXCKiYmdPhqUDl7HGcM=; b=OCZ+mu7tSHO7Cky4ufHFFSZSjMKLgPha54eVJT/XANyiodHiofj2vJ9R+kxlxtuqub mcm+QRqD3eLi/ZzpDhPmvjGe/ssgTXz+4xT466pMSVHgba1YM/kZBqHJ7xMrDladNdJ/ 8nsqyA23k+00HNs6kYIiPNMO1Uymt7ZTd7KiQu1+6y5sPgu72+WTjSz574pvNG/GHG9l ReFj6sGRcPfzQUY9MzRiUH3Ipp3eXqQrAehfNWlNbpxvemf5xFllCi7LiOd8bzjRbjAJ 2upSnfjTu/8+u8US755MDmNKuio583g79FmXazxWCDU7h274+zoxK5ZSKE+1dIuAny6E pVVA== X-Received: by 10.31.0.215 with SMTP id 206mr3938473vka.105.1443635673492; Wed, 30 Sep 2015 10:54:33 -0700 (PDT) Original-Received: by 10.31.139.21 with HTTP; Wed, 30 Sep 2015 10:54:33 -0700 (PDT) In-Reply-To: <560A3C87.3060802@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:107105 Archived-At: --001a113da7c880f9290520fa9f1b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! > Internally, however, internally, it's still possible to issue either > > "toggleFullScreen" or "performZoom". > > What does "internally" mean here? It means that an application can call those function to perform the actions, even though there are no user interface buttons the user can click on. In the Emacs case, setting the `fullscreen' property to the possible legal values invokes one of the system functions `toggleFullScreen' or `performZoom'. > (((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 pixel= s > > (1200 - 1173 - 34) =3D 4. > > What was the 34 about? I probably forgot. "34" should be "23", which is the height of the menu bar. In other words, the effective work area seems to be lacking four pixels at the bottom. I agree with you that I prefer a maximized frame to cover the entire screen. I will try to do some experiments to see if it's possible, and if so, we can discuss if we should modify Emacs to behave this way. > > 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.) > > Does =E2=80=98toggle-frame-maximized=E2=80=99 pass on 1173 or 1176 or 120= 0 as height? Emacs calls the NextStep function `performZoom' without specifying a height. The system, in turn, calls `windowWillUseStandardFrame:' with a suggested frame with the height 1173 (when frame-resize-pixelwise is non-nil). My guess is that we can override this, but I haven't verified this. > 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 chec= kins, > but > > that was before he resigned.) > > You have to apply for membership at Savannah: > > https://savannah.gnu.org/git/?group=3Demacs > > Then Eli (I believe) has to confirm that you are given write access and > finally you have to establish a key pair. Eli will correct me possibly. I got my write access rights today! Thanks for suggesting this. / Anders --001a113da7c880f9290520fa9f1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!

> Internally, however, internal= ly, it's still possible to issue either
> "toggleFullScreen" or "performZoom".

 What does "internally" mean here?

It means that an application can call those function to perform the action= s, even though there are no user interface buttons the user can click on.

In the Emacs case, setting the `fullscreen' pro= perty to the possible legal values invokes one of the system functions `tog= gleFullScreen' or `performZoom'.


> (((name . "SyncMaster") >=C2=A0 =C2=A0 (geometry 0 0 1600 1200)
>=C2=A0 =C2=A0 (workarea 0 23 1600 1173)
>=C2=A0 =C2=A0 (mm-size 432 324)
>=C2=A0 =C2=A0 (frames #<frame *scratch* 0x101099630>)
>=C2=A0 =C2=A0 (source . "NS"))
>=C2=A0 =C2=A0((name . "SyncMaster")
>=C2=A0 =C2=A0 (geometry 1600 0 1600 1200)
>=C2=A0 =C2=A0 (workarea 1600 0 1600 1200)
>=C2=A0 =C2=A0 (mm-size 432 324)
>=C2=A0 =C2=A0 (frames)
>=C2=A0 =C2=A0 (source . "NS")))
>
> Interestingly, the workarea of the primary screen is missing four pixe= ls
> (1200 - 1173 - 34) =3D 4.

 What was the 34 about?=C2=A0 I probably forgot.

=
"34" should be "23", which is the height of the me= nu bar.

In other words, the effective work area se= ems to be lacking four pixels at the bottom.

I agr= ee with you that I prefer a maximized frame to cover the entire screen. I w= ill try to do some experiments to see if it's possible, and if so, we c= an discuss if we should modify Emacs to behave this way.

=C2=A0
> However, the work= area 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 bot= tom left
> corner (which is good), but there are four pixles missing at the TOP o= f the
> screen. (I haven't investigated why, though.)

 Does =E2=80=98toggle-frame-maximized=E2=80=99 pass on 1173 or 1176 or 1200 = as height?

Emacs calls the NextStep functio= n `performZoom' without specifying a height. The system, in turn, calls= `windowWillUseStandardFrame:' with a suggested frame with the height 1= 173 (when frame-resize-pixelwise is non-nil).

My g= uess is that we can override this, but I haven't verified this.


> 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 che= ckins, but
> that was before he resigned.)

 You have to apply for membership at Savannah:

https://savannah.gnu.org/git/?group=3Demacs

Then Eli (I believe) has to confirm that you are given write access and
finally you have to establish a key pair.=C2=A0 Eli will correct me possibl= y.

I got my write access rights today! Than= ks for suggesting this.

/ Anders

--001a113da7c880f9290520fa9f1b--