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

[Anders Lindgren]

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@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

maximize.diff
Description: Text document