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: Mon, 22 Jul 2013 10:22:51 +0200 Message-ID: <51ECEBDB.8010203@gmx.at> References: <51EBEA23.2000805@gmx.at> 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 1374481391 9559 80.91.229.3 (22 Jul 2013 08:23:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Jul 2013 08:23:11 +0000 (UTC) Cc: Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 22 10:23:11 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 1V1BOg-000174-7S for ged-emacs-devel@m.gmane.org; Mon, 22 Jul 2013 10:23:10 +0200 Original-Received: from localhost ([::1]:47736 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1BOf-0000sT-PN for ged-emacs-devel@m.gmane.org; Mon, 22 Jul 2013 04:23:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52855) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1BOa-0000m3-8X for emacs-devel@gnu.org; Mon, 22 Jul 2013 04:23:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1BOW-0007JB-Ik for emacs-devel@gnu.org; Mon, 22 Jul 2013 04:23:04 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:62854) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1BOV-0007IP-Uz for emacs-devel@gnu.org; Mon, 22 Jul 2013 04:23:00 -0400 Original-Received: from [62.47.37.223] ([62.47.37.223]) by mail.gmx.com (mrgmx003) with ESMTPA (Nemesis) id 0LnfuZ-1UTmWb21dv-00hvR7 for ; Mon, 22 Jul 2013 10:22:58 +0200 In-Reply-To: X-Provags-ID: V03:K0:zMJQ0ky1FdnDIgAFDotvVxg0mEeUbrWTff8KUhmzWSU97RlADCl shzv+bQOr6GmMfwFpN+KgzAl63iLG0JIgTOnP+HgGFLYAQw+kxp60RRPmLoaU+js1MVtvXe KxXeUyLwxw1h27o7gWPnSwiUYv3TiW+VoDlz7Ske02ZBoQ8uzfYtWVA79iOxs65hpUaXm1P TmP+3n8ape0ONEgo3qW3g== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 212.227.15.15 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:162066 Archived-At: > 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. Admittedly, it's not easy to specify what the height should be in this case. > 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? There are various ways to deal with this. Here on Windows most GUN/Linux-derived applications either truncate menu bar entries if they don't fit or don't allow to make a window smaller than the actual width of its menu bar. Application display a combo box usually only for objects they draw themselves. > 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? IIUC on Windows we would need a function like `w32-frame-rect' I posted earlier and, in addition, need access to a NONCLIENTMETRICS structure to determine whether the menubar wrapped or its font is just too high. This means that we would have to say whether the height of the window rectangle minus those of client rectangle, caption and two borders equals the height of a menubar (or some multiple). >> 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. The idea would be to start with an invisible frame and making it visible once we're done. But I'm 100% sure that many platforms won't get us the metrics of an invisible frame. >> 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. I hardly ever know whether and when `modify-frame-parameters' has a visible effect. This function is a time bomb. martin