From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: [Fwd: Frame Height Different for Default Frame and Additional Frames] Date: Sat, 5 Jan 2008 10:08:49 -0800 Message-ID: References: <477FBF6E.20307@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1199556544 2874 80.91.229.12 (5 Jan 2008 18:09:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2008 18:09:04 +0000 (UTC) Cc: bob@rattlesnake.com, rms@gnu.org, emacs-devel@gnu.org To: =?ISO-8859-15?Q?Jan_Dj=E4rv?= , "martin rudalics" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 05 19:09:24 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JBDSW-0005lZ-3U for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 19:09:24 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBDS9-0006Zi-CP for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 13:09:01 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JBDS5-0006Yg-FY for emacs-devel@gnu.org; Sat, 05 Jan 2008 13:08:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JBDS3-0006W9-UX for emacs-devel@gnu.org; Sat, 05 Jan 2008 13:08:57 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBDS3-0006W0-Pd for emacs-devel@gnu.org; Sat, 05 Jan 2008 13:08:55 -0500 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JBDRz-0004EZ-Qe; Sat, 05 Jan 2008 13:08:52 -0500 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m05I8lCH018319; Sat, 5 Jan 2008 11:08:47 -0700 Original-Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m05AbimS013613; Sat, 5 Jan 2008 11:08:41 -0700 Original-Received: from 141.144.88.86 by acsmt351.oracle.com with ESMTP id 3479109871199556506; Sat, 05 Jan 2008 10:08:26 -0800 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <477FBF6E.20307@swipnet.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:86203 Archived-At: > > Did we already settle on a "right" way to do this? Robert expressed the > > desire to keep the number of text lines invariant. ISTR others wanted > > the size of the frame on the screen stay invariant. At least a similar > > issue was recently brought up for menubars. Finally, I'm interested how > > changes of menu-bar-lines/tool-bar-lines are supposed to be applied and > > handled - I'm quite lost in this context. > > I don't think we did. But frame size can't in general stay constant as > we have wm hints. For example, I have 13 pixels of text height. > That gives min resize 13. The tool bar is 36 pixels. So when the > tool bar goes, either we increase text size by 3 (== 39, 3 > additional pixels) or by 2 (26, decrease by 10 pixels). > > I'll implement whatever seems easiest, and then people can suggest > alternatives after that. The fact that it is not always possible to maintain exactly the same overall frame size because that size is not always an integral number of characters is not a reason to not try to maintain the size as closely as possible. Please don't simply "implement whatever seems easiest". It is likely that there are different preferences for this based on different uses of frames. Someone who typically uses frames (e.g. non-nil pop-up-frames) might want the frame size to remain the same (or as close to that as possible). Such a user will want to fit frames, tile them, and perform other operations for which the overall (outside) frame dimensions are significant. I and some others are in this group. Someone else might want the text content within the frame to remain constant. Such a user might not care so much about the outside frame dimensions. The right approach to this is to provide a user option for it. There is no sense arguing over which frame-size treatment is best in this regard, and it does not make sense to simply code "whatever seems easiest" and then entertain suggestions for changes after that. Let's try to get it right now, and provide an option to let users choose the behavior they want - different users use frames differently. We know that character size does not always map exactly to pixel size, but that's not a reason to not try to DTRT.