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

Previous Next

Full log

Message #197 received at 21415 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#21415: 25.0.50;
 Emacs Trunk -- pixelwise width/height for x-create-frame
Date: Sun, 27 Sep 2015 20:53:39 +0200

[Message part 1 (text/plain, inline)]

Hi,

I found one problem related to `toggle-to-maximized'. If this happened
right after `frame-resize-pixelwise' was set to a non-nil value, the
NSWindow parameter `resizeIncrement' must be updated. If this does not
occur, the frame size is rounded down to only accommodate full characters.
The extra space was distributed evenly above and below the frame. The
attached patch fixes this issue.

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. The
documentation to `windowWillUseStandardFrame' says:

    "The size of the current screen, which is the screen containing the
largest part of the window's current frame, possibly reduced on the top,
bottom, left, or right, depending on the current interface style."

Effectively, this mean that the frame is reduced one pixel on the top (if
the menu bar is visible) and four pixels at the bottom. This corresponds to
how other applications, like Chrome, works.

I think it would be relatively easy to override this (well, at least the
four pixels at the bottom), but I'm not sure if we should and, if so, under
which conditions. (I can image that some users would like Emacs to fill the
entire screen whereas others might prefer the standard four pixels to be
unused at the bottom.)

In the Info documentation to the `fullscreen' frame parameter, there are
two values missing: `nil' and `fullscreen'. The former indicates that the
frame is in non-maximized state and the latter seems to behave like
`fullboth'. Interestingly, the function `toggle-frame-fullscreen' seems to
use this undocumented parameter value. (In addition, there are some control
characters showing on the first line.)

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 release.

Sincerely,
    Anders Lindgren

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

> > 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.
>
> OK.  As far as frame resizing is concerned I wrote some rudimentary
> Elisp support.  Set the variable ‘frame-size-history’ to a value like
> '(100) and you will get a (partly cryptic) list of requests to resize a
> frame and whether and how the request got honored.
>
> > By the way, is
> > there some kind of deadline coming up?
>
> Not for bugs like this.  It's only short before a release that we only
> fix regressions introduced since the last release.
>
> > 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.)
>
> One thing that should work uniformly accross platforms is the
> ‘frame-geometry’ function as well as the recently introduced
> ‘frame-edges’.  Since I was never able to verify these for OS X it would
> be a good start to make sure they deliver correct results there first.
> Done that, we should have a common platform to discuss the remaining
> issues.
>
> > In addition, we really must write test
> > cases automatically walking through all transitions, ensuring that
> nothing
> > breaks in the future,
>
> One problem with automatic test cases is that numbers may lie about the
> effect you see on screen.  For example, Emacs can resize your scroll bar
> width with completely correct metrics but since Gtk+ usually refuses to
> change scroll bar widths, the visual appearance is devastating.  But
> obviously, automatic test cases would be very useful.
>
> > but also as this is a good way to describe the
> > intended behavior.
>
> Such description should be found in the frame geometry section of the
> Elisp manual.
>
> > I don't know what you mean by "fullboth", so I can't comment on what
> would
> > happen when you collate "fullscreen" and "fullboth".
>
> "fullboth" is our misnomer for "maximized", that is, the frame should
> occupy the full work area of the display and its "maximize" button
> should indicate that the frame can be restored to its normal size (the
> latter implies that a maximized frame usually keeps its title bar).
>
> A "fullscreen" frame, OTOH, occupies the entire display area (including
> a task bar) and has no title bar.
>
> martin
>
>

[Message part 2 (text/html, inline)]

[maximize.diff (text/plain, attachment)]

Previous Next

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