From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: frame size&position woes Date: Sun, 21 Jul 2013 14:56:04 +0200 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1374411416 31598 80.91.229.3 (21 Jul 2013 12:56:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Jul 2013 12:56:56 +0000 (UTC) To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 21 14:56:57 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 1V0tC1-0006qN-39 for ged-emacs-devel@m.gmane.org; Sun, 21 Jul 2013 14:56:53 +0200 Original-Received: from localhost ([::1]:55974 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0tC0-0000YK-N0 for ged-emacs-devel@m.gmane.org; Sun, 21 Jul 2013 08:56:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0tBx-0000YB-9u for emacs-devel@gnu.org; Sun, 21 Jul 2013 08:56:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V0tBu-0007C1-5N for emacs-devel@gnu.org; Sun, 21 Jul 2013 08:56:49 -0400 Original-Received: from mail-ea0-x22d.google.com ([2a00:1450:4013:c01::22d]:44980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0tBt-0007Bp-Uq for emacs-devel@gnu.org; Sun, 21 Jul 2013 08:56:46 -0400 Original-Received: by mail-ea0-f173.google.com with SMTP id g15so3283044eak.32 for ; Sun, 21 Jul 2013 05:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Ges8xO0Uvo2707WUlyWbN7+PvjKnQeJ/fJVjzjYYNS0=; b=ZHfo6BmZakDc2M9Ei3d/Ud79L+WhDrlwkzCMicXRV1AfGt1jIG0WAgWcHPcvuXbNJa j5rKoKZNhSlJgG+L00YbPyaU7TgaZ4Z0iev8qG01ThRQOtJpnMatw6ohc49L47vezjyN Sz7U1sPHRQ9FbiHa7BkojlIsDLmKNamDgfCOKijfnaEJtYeaQOQvyni56WcvPW+2Y6Tt ULNIeQnsO4l0eS+MP8Ho+rh33OrYT3E9N1yh8oOoXDHdtzo3sPSvWc6crAZcPH+DIPz1 DHs9HfkovaSR8eN/WKtZuUsiw+RK/IKYIpT+jg624yI5vhRuHvoKKm8rpPRCfEa0jCkL zCeg== X-Received: by 10.14.218.8 with SMTP id j8mr23315722eep.129.1374411404514; Sun, 21 Jul 2013 05:56:44 -0700 (PDT) Original-Received: by 10.14.142.4 with HTTP; Sun, 21 Jul 2013 05:56:04 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::22d 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:162051 Archived-At: Currently, our API to obtain the dimensions and position of a frame is kind of broken. The part related to tool-bars has already been (briefly) discussed in bug#14795. Fortunately I found a workaround for desktop-restore-frames (set tool-bar-lines to 0, create/modify frame, set tool-bar-lines back to its intended value). 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" M-: (frame-height) => 38 ;; (3) (1) is the "real" height, or at least, what we do say that's the real height. (2) happens even when (frame-parameter nil 'menu-bar-lines) is still 1 (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. If all that behavior is considered sane, I'm spechless. 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). 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. 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. 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? J