[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
frame size&position woes
From: |
Juanma Barranquero |
Subject: |
frame size&position woes |
Date: |
Sun, 21 Jul 2013 14:56:04 +0200 |
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
- frame size&position woes,
Juanma Barranquero <=
- Re: frame size&position woes, Juanma Barranquero, 2013/07/21
- Re: frame size&position woes, martin rudalics, 2013/07/21
- Re: frame size&position woes, Juanma Barranquero, 2013/07/21
- Re: frame size&position woes, Juanma Barranquero, 2013/07/21
- Re: frame size&position woes, martin rudalics, 2013/07/22
- Re: frame size&position woes, Juanma Barranquero, 2013/07/22
- Re: frame size&position woes, Eli Zaretskii, 2013/07/22
- Re: frame size&position woes, Juanma Barranquero, 2013/07/22
- Re: frame size&position woes, Eli Zaretskii, 2013/07/22
- Re: frame size&position woes, Juanma Barranquero, 2013/07/23