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: 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: Tue, 22 Sep 2015 10:54:03 +0200
[Message part 1 (text/plain, inline)]
Hi!

I can take a look at it. However, the experience I had with the previous
bug was that it's immensely hard to follow what happens when it comes to
frame resizing and placement. So what I will do is to first reimplement the
NSTRACE package and then start looking for the problem. By the way, is
there some kind of deadline coming up?

Also, things are starting to get so complicated so that we would need to
state what each concept mean so that they can be implemented the same way
on all systems. (When I wrote my "multicolumn" package I found tons and
tons of things that differed between systems, I just want to make sure we
don't introduce more such things.) In addition, we really must write test
cases automatically walking through all transitions, ensuring that nothing
breaks in the future, but also as this is a good way to describe the
intended behavior.

I don't know what you mean by "fullboth", so I can't comment on what would
happen when you collate "fullscreen" and "fullboth".

/ Anders


On Tue, Sep 22, 2015 at 8:38 AM, martin rudalics <rudalics <at> gmx.at> wrote:

> > In OS X Yosemite, the "maximize" button (the green round button on the
> top
> > left of the screen) starts fullscreen mode.
>
> This is what ‘toggle-frame-fullscreen’ is supposed to do.
>
> > `toggle-frame-maximized', on the other hand, tries to resize the frame so
> > that it covers an entire monitor, but without entering full-screen mode
> > (which is the way it should work).
>
> What if the next OS X generation changes policy again and asks for some
> sort of "fullboth"?
>
> > Unfortunately, there is a bit of empty
> > space above and below the Emacs frame. It looks like this is due to the
> > fact that there isn't enough space to create another full line of text.
> > When setting `frame-resize-pixelwise' to t, unfortunately, it still
> doesn't
> > cover the entire display, and the behaviour is a bit more random, with
> the
> > frame repositioning itself slightly differently when
> > `toggle-frame-maximized' is called multiple times.
>
> We'd have to fix this one way or the other.  Maybe by temporarily
> collating "fullscreen" and "fullboth" for the NS builds.
>
> The important thing is to synchronize the value of the ‘fullscreen’
> frame parameter with the actual state of the frame as seen by both, the
> window manager (or the OS) and the user.  The state of the frame
> includes its size, its decorations and the state of the "maximize"
> button.  In my experience, having ‘toggle-frame-maximized’ follow
> ‘toggle-frame-fullscreen’ can be very tricky in this regard.
>
> > I didn't manage to make it fill both my monitors, only one. (How does the
> > command work on other systems?)
>
> I can't tell because I use only one monitor.
>
> > The documentation refers to an undefined
> > variable, x-frame-normalize-before-maximize.
>
> This variable is for X only.  I'll fix that in the documentation.
>
> martin
>
>
[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.