Re: frame size&position woes

[martin rudalics]

> Now I'm dealing with something related to bug#25 (yeah, the report is
> that old, and even older), which Glenn merged with #14795 though they
> are really different.
>
> The problem I'm seeing is this:
>
>   emacs -Q
>   M-: (frame-height) <RET>    => 38   ;; (1)
>   ;; Now, make the frame narrower until the menu wraps just after "Tools"
>   M-: (frame-height) <RET>    => 36   ;; (2)
>   ;; For extra fun, make the frame just wide enough to wrap after "Help"

Gets me still 36 (wrapping _before_ "Help").

>   M-: (frame-height) <RET>    => 38   ;; (3)
>
> (1) is the "real" height, or at least, what we do say that's the real height.

It's not possible to tell what the real height of a frame is.

> (2) happens even when (frame-parameter nil 'menu-bar-lines) is still 1

FWIW this parameter is ignored on Windows since the later itself resizes
the menubar (basically, we'd have to deduce the number of lines from the
frame heights).  One can, however, truncate menubars on Windows which is
the default on GNU/Linux

> (3) happens (depending on your default font, I suppose), because when you do
>     M-: whatever you're using the minibuffer menu, which has less items.

I'm not sure what you mean here.  Note that on Windows the toolbar is
included in the frame's height.

> If all that behavior is considered sane, I'm spechless.

IIRC Windows won't tell you whether it wrapped the menubar.  So you can
tell only by comparing the sizes of the outer rectangle and the client
rectangle taking into account the font of the menubar.

> To fix that problem for desktop-restore-frames (and it is a problem,
> because a frame with a wrapped menu gets shorter and shorter with each
> save/restore cycle). other than adding new APIs to get real
> dimensions, the only answer I can think of is
>
>   (let ((mblines (frame-parameter *f* 'menu-bar-lines)))
>     (set-frame-parameter *f* 'menu-bar-lines 0)
>     (prog1
>         (frame-height *f*)
>       (set-frame-parameter *f* 'menu-bar-lines mblines)))
>
> which works, but it is visible to the user (removing the menu, even
> briefly, obviously triggers redisplay of the frame).

I never tried too experiment with invisible frames and getting
information from them.  Maybe they could be used here.

> Which brings me to that other problem:
>
> Just yesterday I added a fix for saving & restoring iconified frames.
> Iconified frames have nonsensical positions (left + -32000) (top +
> -32000), so I have to remove them to allow Emacs to set them at a
> default position when restored. The ideal answer would be to get the
> real position of the de-iconified frame, but again... to get these
> values I must de-iconize, record the values, re-iconize again... which
> is visible to the user.

On Windows you should be able to get the normal position and size of an
iconified frame.  I'm not sure about other systems.  In the worst case
we'd have to save them before processing an iconify request.

> And the same happens with maximized / fullscreen / fullwidth /
> fullheight frames. I'm not storing their original size & position to
> avoid the user the "flash" of restoring/maximizing back.

We could "store" the values softly, that is, not via
`modify-frame-parameters'.

> At this point, I'm really thinking of just adding an option
> desktop-restore-frames-extra-accurate (name irrelevant) that, when
> set, will give me permission to freely manipulate (temporarily)
> frames' menu bars, tool bars, maximized states and whatever I need in
> order to get the correct info. The user will trade a bit of discomfort
> when saving the desktop for a better restoring experience.
>
> But, to get back on track, I strongly believe we need better ways of
> asking about basic frame metrics. Does anyone else agree, or I'm being
> grumpy and unreasonable?

We have not even agreed upon what frame metrics are.  Asking here will
get you at least five different opinions.

martin