[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: frame size&position woes
From: |
Juanma Barranquero |
Subject: |
Re: frame size&position woes |
Date: |
Mon, 22 Jul 2013 22:36:33 +0200 |
On Mon, Jul 22, 2013 at 5:52 PM, Eli Zaretskii <address@hidden> 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
- 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/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 <=
- Re: frame size&position woes, Eli Zaretskii, 2013/07/22
- Re: frame size&position woes, Juanma Barranquero, 2013/07/23
- Re: frame size&position woes, Eli Zaretskii, 2013/07/23
- Re: frame size&position woes, Juanma Barranquero, 2013/07/24
- Re: frame size&position woes, Eli Zaretskii, 2013/07/24
- Re: frame size&position woes, Juanma Barranquero, 2013/07/24
- Re: frame size&position woes, Eli Zaretskii, 2013/07/24
- Re: frame size&position woes, Juanma Barranquero, 2013/07/24
- Re: frame size&position woes, Eli Zaretskii, 2013/07/24
- Re: frame size&position woes, Juanma Barranquero, 2013/07/24