Re: frame size&position woes

[Juanma Barranquero <lekktu@gmail.com>]

On Mon, Jul 22, 2013 at 5:52 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Is your problem, in practice, only with those weirdo frames that have
> their tool bars and/or menu bars wrapped?  Or do you have problems
> with the more "dull" use cases as well?

Tool bars are much better behaved than menu bars, even when wrapped,
though there's bug#14795, that some consider a feature. "Dull" use
cases, as you say, don't pose any problem (or none related to frame
size anyway; there's still things to fix but unrelated to the physical
appearance of frames).

> If the latter, can you describe the unsolved problem(s) you have in
> that case?

The biggest problem right now is not related to frame-height, but
frame-pixel-height, that is, we'd need a function that returned (for
every available window system and toolkit) the real width & height of
an Emacs frame in pixels, not of the client area, but the whole frame.
It's the only sane way to check whether a frame is currently visible
in a monitor.

> People who wrap menus deserve that.

On one hand, I agree with you. It's ugly and I would never do it. On
the other hand, I'm not trying to make desktop-restore-frames work for
me, but for as many users as possible. And we have an elisp API to
create a frame without menu-bar or remove it from one (via frame
parameters), but I don't think we have a UI command to do that, so if
the user wants to use menus, but s/he also wants to have a narrow
frame for some reason (let's say, to follow the output of some command
which only prints short lines), s/he's forced to make the frame wider,
or accept a wrapped menu. If s/he then saves & restores...

> It's not complex.  AFAIK, "(make-frame '((height . N)))" creates a
> frame whose "(frame-height)" returns N plus the value returned by
> tool-bar-lines-needed.

I didn't even know that tool-bar-lines-needed existed. Anyway, I still
think it's horrible that height means something different for
make-frame and set-frame-parameter/modify-frame-parameters, but as
there are workarounds, I won't argue the point again.

> I expect the same to be true on X, with the
> exception of a GTK build, where we might need to do something special.

Well, let's hope someone tries desktop-restore-frames on GTK and
reports the result.

> Does this solve the problem with visible frames?  If not, what is
> left?

As said above, knowing their real, physical size in pixels, instead of
some Emacs interpretation of it in arbitrary "character" units, would
be helpful.

   Juanma