Re: frame size&position woes

[Juanma Barranquero]

On Sun, Jul 21, 2013 at 4:03 PM, martin rudalics <address@hidden> wrote:

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

Yep, that depends on the font, etc. But the menu for the minibuffer
has fewer items that the menu for lisp-interaction, so if you play a
little with the frame width, you'll get to a point where the menu for
the main window is wrapped, but still M-: (frame-height) <RET> gets
you the same size that if it weren't, because during M-:
(frame-height), it is not.

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

Didn't I say as much?

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

Yes, so perhaps the trouble that I'm reporting only happens on
Windows. It's still quite real and annoying, though.

> One can, however, truncate menubars on Windows which is
> the default on GNU/Linux

Assuming that IUYC, I'm surprised that's the default on GNU/Linux. Is
there any key combo or another UI element to get to the truncated menu
entries?

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

I'm not talking about the toolbar, but what I explained above, about
the wrapped menu bar.

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

Wonderful. All this boils down to something we discussed earlier: it
would be useful to have an API to get the height of a complete frame,
in some units (pixels, etc.), like frame-pixel-height, but coherent
across toolkits. And, a way to create or resize a frame using these
same units; I don't think that's possible right now, is it?

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

I've tried making frames invisible and trying to extract information
from them. Doesn't really work (depends on the info, I think) and
making a frame invisible and visible again is also user noticeable.

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

But it is not really useful if it's not done for all window systems /
GUI toolkits.

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

When and how? Storing them via m-f-p is not a problem, as long as they
are not called left/top/width/height, BTW.

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

Yep. But meanwhile, what we have is a mishmash of metrics, options,
units and whatnot.

   J