frame size&position woes

[Juanma Barranquero]

Currently, our API to obtain the dimensions and position of a frame is
kind of broken.

The part related to tool-bars has already been (briefly) discussed in
bug#14795. Fortunately I found a workaround for desktop-restore-frames
(set tool-bar-lines to 0, create/modify frame, set tool-bar-lines back
to its intended value).

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"
  M-: (frame-height) <RET>    => 38   ;; (3)

(1) is the "real" height, or at least, what we do say that's the real height.
(2) happens even when (frame-parameter nil 'menu-bar-lines) is still 1
(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.

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

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

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.

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.

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?

     J