|
From: | Anders Lindgren |
Subject: | bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame |
Date: | Mon, 28 Sep 2015 23:35:50 +0200 |
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.
you do that?
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’".
> 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?
> (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.
[Prev in Thread] | Current Thread | [Next in Thread] |