From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: frame size&position woes Date: Sun, 21 Jul 2013 16:03:15 +0200 Message-ID: <51EBEA23.2000805@gmx.at> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1374415407 3264 80.91.229.3 (21 Jul 2013 14:03:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Jul 2013 14:03:27 +0000 (UTC) Cc: Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 21 16:03:28 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V0uES-0004Dg-6u for ged-emacs-devel@m.gmane.org; Sun, 21 Jul 2013 16:03:28 +0200 Original-Received: from localhost ([::1]:39732 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0uER-0007Fm-Fz for ged-emacs-devel@m.gmane.org; Sun, 21 Jul 2013 10:03:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0uEO-0007Ff-TO for emacs-devel@gnu.org; Sun, 21 Jul 2013 10:03:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V0uEN-0003bB-Mv for emacs-devel@gnu.org; Sun, 21 Jul 2013 10:03:24 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:59725) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0uEN-0003b7-Dt for emacs-devel@gnu.org; Sun, 21 Jul 2013 10:03:23 -0400 Original-Received: from [62.47.39.27] ([62.47.39.27]) by mail.gmx.com (mrgmx003) with ESMTPA (Nemesis) id 0MU1MP-1Ua8AV0Pvl-00QkG8 for ; Sun, 21 Jul 2013 16:03:22 +0200 In-Reply-To: X-Provags-ID: V03:K0:Nzi0NqI8cTBS0djQ+Se2dOeV2I4wmwiRgRhQq4TWirAs0JYF+if cIUKc3QUGOm82G2bP+3+p8pytrPYtotQgl+A8v1W8yHPr1hBvtuQ//7LkOCWzOQAV22AMAZ p7D/i/6UCfHfvylFgIOR/ZutIhZygeQN587v7dhplcFc6nU8FiueiA5P9YGz4UeeFEUOP3f Q2reMlSl1rNlmsBsoo4Zw== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.17.21 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:162053 Archived-At: > Now I'm dealing with something related to bug#25 (yeah, the report is > that old, and even older), which Glenn merged with #14795 though they > are really different. > > The problem I'm seeing is this: > > emacs -Q > M-: (frame-height) => 38 ;; (1) > ;; Now, make the frame narrower until the menu wraps just after "Tools" > M-: (frame-height) => 36 ;; (2) > ;; For extra fun, make the frame just wide enough to wrap after "Help" Gets me still 36 (wrapping _before_ "Help"). > M-: (frame-height) => 38 ;; (3) > > (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. > (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). One can, however, truncate menubars on Windows which is the default on GNU/Linux > (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. > If all that behavior is considered sane, I'm spechless. 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. > To fix that problem for desktop-restore-frames (and it is a problem, > because a frame with a wrapped menu gets shorter and shorter with each > save/restore cycle). other than adding new APIs to get real > dimensions, the only answer I can think of is > > (let ((mblines (frame-parameter *f* 'menu-bar-lines))) > (set-frame-parameter *f* 'menu-bar-lines 0) > (prog1 > (frame-height *f*) > (set-frame-parameter *f* 'menu-bar-lines mblines))) > > which works, but it is visible to the user (removing the menu, even > briefly, obviously triggers redisplay of the frame). I never tried too experiment with invisible frames and getting information from them. Maybe they could be used here. > Which brings me to that other problem: > > Just yesterday I added a fix for saving & restoring iconified frames. > Iconified frames have nonsensical positions (left + -32000) (top + > -32000), so I have to remove them to allow Emacs to set them at a > default position when restored. The ideal answer would be to get the > real position of the de-iconified frame, but again... to get these > values I must de-iconize, record the values, re-iconize again... which > is visible to the user. 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. > And the same happens with maximized / fullscreen / fullwidth / > fullheight frames. I'm not storing their original size & position to > avoid the user the "flash" of restoring/maximizing back. We could "store" the values softly, that is, not via `modify-frame-parameters'. > At this point, I'm really thinking of just adding an option > desktop-restore-frames-extra-accurate (name irrelevant) that, when > set, will give me permission to freely manipulate (temporarily) > frames' menu bars, tool bars, maximized states and whatever I need in > order to get the correct info. The user will trade a bit of discomfort > when saving the desktop for a better restoring experience. > > But, to get back on track, I strongly believe we need better ways of > asking about basic frame metrics. Does anyone else agree, or I'm being > grumpy and unreasonable? We have not even agreed upon what frame metrics are. Asking here will get you at least five different opinions. martin