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: Re: frame size&position woes Date: Sun, 21 Jul 2013 17:42:00 +0200 Message-ID: References: <51EBEA23.2000805@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1374421367 25863 80.91.229.3 (21 Jul 2013 15:42:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Jul 2013 15:42:47 +0000 (UTC) Cc: Emacs developers To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 21 17:42:49 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 1V0vma-0003OE-F6 for ged-emacs-devel@m.gmane.org; Sun, 21 Jul 2013 17:42:48 +0200 Original-Received: from localhost ([::1]:38334 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0vma-0001Ne-3m for ged-emacs-devel@m.gmane.org; Sun, 21 Jul 2013 11:42:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0vmW-0001KS-4x for emacs-devel@gnu.org; Sun, 21 Jul 2013 11:42:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V0vmT-0001HR-Gh for emacs-devel@gnu.org; Sun, 21 Jul 2013 11:42:44 -0400 Original-Received: from mail-ea0-x230.google.com ([2a00:1450:4013:c01::230]:38555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0vmT-0001H6-A6 for emacs-devel@gnu.org; Sun, 21 Jul 2013 11:42:41 -0400 Original-Received: by mail-ea0-f176.google.com with SMTP id z15so3332918ead.35 for ; Sun, 21 Jul 2013 08:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dn6+NODIfeLFwnKbNrNGGfpUsuAYhgg6hdIcZXQ1Kxg=; b=Y2KqZs3rJRlqxVzP6qpo7QUOqgG+xYT2GInLS8PXinpRHWo2EKK06+KRWEmNqaZK9S r4eYNdqF6THHXAIBGdvKTDmBM4wnuZ3sA2rsLikjJjv/eQXMwK3YlERNdJ/xkP5MhNTT HRvssqsKS0KZ2eh52QDytln5PHBnlatezxbqQ2E492II2LhxK65CGuIvNY4uOXE4EYCs gZcESkVijOGusxsjAxjs7AaHOZ/Yl+D/h5FIFctGHoBorukgy0TLEBSYzoXWftyn1n5T PNOFkTwfVB3N1eXZpcBS+wZG/ApqVP2Gz9DdS+djODvQU5ebca4vk+6Cx3K7/6aFeGm2 iSpg== X-Received: by 10.15.76.71 with SMTP id m47mr23492601eey.70.1374421360497; Sun, 21 Jul 2013 08:42:40 -0700 (PDT) Original-Received: by 10.14.142.4 with HTTP; Sun, 21 Jul 2013 08:42:00 -0700 (PDT) In-Reply-To: <51EBEA23.2000805@gmx.at> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::230 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:162055 Archived-At: On Sun, Jul 21, 2013 at 4:03 PM, martin rudalics wrote: > Gets me still 36 (wrapping _before_ "Help"). Yep, that depends on the font, etc. But the menu for the minibuffer has fewer items that the menu for lisp-interaction, so if you play a little with the frame width, you'll get to a point where the menu for the main window is wrapped, but still M-: (frame-height) gets you the same size that if it weren't, because during M-: (frame-height), it is not. >> (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. Didn't I say as much? >> (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). Yes, so perhaps the trouble that I'm reporting only happens on Windows. It's still quite real and annoying, though. > One can, however, truncate menubars on Windows which is > the default on GNU/Linux Assuming that IUYC, I'm surprised that's the default on GNU/Linux. Is there any key combo or another UI element to get to the truncated menu entries? >> (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. I'm not talking about the toolbar, but what I explained above, about the wrapped menu bar. > 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. Wonderful. All this boils down to something we discussed earlier: it would be useful to have an API to get the height of a complete frame, in some units (pixels, etc.), like frame-pixel-height, but coherent across toolkits. And, a way to create or resize a frame using these same units; I don't think that's possible right now, is it? > I never tried too experiment with invisible frames and getting > information from them. Maybe they could be used here. I've tried making frames invisible and trying to extract information from them. Doesn't really work (depends on the info, I think) and making a frame invisible and visible again is also user noticeable. > 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. But it is not really useful if it's not done for all window systems / GUI toolkits. > We could "store" the values softly, that is, not via > `modify-frame-parameters'. When and how? Storing them via m-f-p is not a problem, as long as they are not called left/top/width/height, BTW. > We have not even agreed upon what frame metrics are. Asking here will > get you at least five different opinions. Yep. But meanwhile, what we have is a mishmash of metrics, options, units and whatnot. J