[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: frame size&position woes

From: Eli Zaretskii
Subject: Re: frame size&position woes
Date: Tue, 23 Jul 2013 05:45:37 +0300

> From: Juanma Barranquero <address@hidden>
> Date: Mon, 22 Jul 2013 22:36:33 +0200
> Cc: martin rudalics <address@hidden>, Emacs developers <address@hidden>
> > 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.

Why do you need all that?  Isn't frame-height, frame-width, and the
top and left frame parameters enough to restore the frame's dimensions
and position?

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

...then the frame will not be restored to the exact size it was, but
maybe one or two lines more or less.  I don't see a big problem here,
it's a marginal use case, one I doubt even exists.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]