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

[martin rudalics]

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

Makes sense.  Pushed as 73b0901..e55460e to master.

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

Usually it shouldn't, for maximizing.  The problem as far as I
understand is that NS doesn't have the concept of a "maximized" frame.

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

When you do what, in Chrome?  Try maximizing the Chrome window?  How do
you do that?

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

We have the concept of a "workarea" as it's returned by
‘display-monitor-attributes-list’.  On all systems I know of, a
"maximized" frame occupies the full workarea, a "fullwidth" frame the
full width of the workarea and a "fullheight" frame the full height of
the workarea. (I have no idea how these concepts expand to multiple
monitors though.)  How do the four unused pixels relate to your
workarea?

> 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

nil means "neither of ‘maximized’, ‘fullwidth’, ‘fullheight’ or
‘fullboth’".

> and the latter seems to behave like
> `fullboth'.

‘fullscreen’ should not be used.  I kept it in because I had the faint
feeling that at some time it was used isntead of ‘fullboth’.

> Interestingly, the function `toggle-frame-fullscreen' seems to
> use this undocumented parameter value.

It accepts it IIUC but it does not store it.  Or what do you mean?

Note that the documentations is still not very clear on the entire
subject, mostly so because I don't know how other systems handle it.
For example, xfce which I use on Debian seems to correctly cooperate
with Emacs via the extended window manager hints with one exception: The
state of the "resize" button in the title bar is the same for
‘fullheight’ and ‘maximized’.  Consequently, using that button doesn't
quite DTRT for a full height frame.

On Windows, Emacs controls ‘fullheight’ and ‘fullwidth’ and I see no
such problem.  But you will nowhere find a description of the semantics
of ‘toggle-frame-maximized’ when the frame is in the ‘fullboth’ state
and was ‘maximized’ before.

Note also in this context that Stefan's bug #10670 "`fullscreen' frame
parameter ill-named" is yet unresolved:

  The frame parameter `fullscreen' is ill-named: I think that it should be
  renamed to `maximized' with accepted values nil, `vertical',
  `horizontal', `both', or `fullscreen'.

I agree with his diagnosis but I disagree with the cure.  And for
compatibility reasons we would have to accept the old values anyway.

> (In addition, there are some control
> characters showing on the first line.)

Please elaborate.

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

Fine.  Can you please get yourself write access to the git repository so
you can install it when it's ready?  I feel some unease installing
larger changes on systems where I cannot check the consequences myself
immediately.

martin