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

Previous Next

Package: emacs;

Reported by: Keith David Bershatsky <esq <at> lawlist.com>

Date: Fri, 4 Sep 2015 17:43:01 UTC

Severity: wishlist

Found in version 25.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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: bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame
Date: Wed, 30 Sep 2015 19:54:33 +0200
[Message part 1 (text/plain, inline)]
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 #<frame *scratch* 0x101099630>)
> >    (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) = 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 ‘toggle-frame-maximized’ pass on 1173 or 1176 or 1200 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ärv did the checkins,
> but
> > that was before he resigned.)
>
> You have to apply for membership at Savannah:
>
> https://savannah.gnu.org/git/?group=emacs
>
> 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
[Message part 2 (text/html, inline)]

This bug report was last modified 4 years and 251 days ago.

Previous Next


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