Re: frame size&position woes

[martin rudalics]

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

Admittedly, it's not easy to specify what the height should be in this
case.

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

There are various ways to deal with this.  Here on Windows most
GUN/Linux-derived applications either truncate menu bar entries if they
don't fit or don't allow to make a window smaller than the actual width
of its menu bar.  Application display a combo box usually only for
objects they draw themselves.

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

IIUC on Windows we would need a function like `w32-frame-rect' I posted
earlier and, in addition, need access to a NONCLIENTMETRICS structure to
determine whether the menubar wrapped or its font is just too high.
This means that we would have to say whether the height of the window
rectangle minus those of client rectangle, caption and two borders
equals the height of a menubar (or some multiple).

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

The idea would be to start with an invisible frame and making it visible
once we're done.  But I'm 100% sure that many platforms won't get us the
metrics of an invisible frame.

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

I hardly ever know whether and when `modify-frame-parameters' has a
visible effect.  This function is a time bomb.

martin