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: Minimum frame size in Windows Date: Tue, 12 Dec 2006 13:37:00 -0800 Message-ID: References: NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1165959455 22547 80.91.229.10 (12 Dec 2006 21:37:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 12 Dec 2006 21:37:35 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 12 22:37:34 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by dough.gmane.org with esmtp (Exim 4.50) id 1GuFJc-0004fR-QD for ged-emacs-devel@m.gmane.org; Tue, 12 Dec 2006 22:37:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuFJc-0002Wy-49 for ged-emacs-devel@m.gmane.org; Tue, 12 Dec 2006 16:37:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GuFJL-0002WW-RW for emacs-devel@gnu.org; Tue, 12 Dec 2006 16:37:15 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GuFJK-0002VR-4k for emacs-devel@gnu.org; Tue, 12 Dec 2006 16:37:15 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuFJJ-0002V6-Lc for emacs-devel@gnu.org; Tue, 12 Dec 2006 16:37:13 -0500 Original-Received: from [148.87.113.118] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GuFJJ-0005ew-9a for emacs-devel@gnu.org; Tue, 12 Dec 2006 16:37:13 -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 kBCLb9CF018613 for ; Tue, 12 Dec 2006 14:37:09 -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.1.7) with ESMTP id kBCLY1mN014296 for ; Tue, 12 Dec 2006 14:37:09 -0700 Original-Received: from dhcp-amer-csvpn-gw2-141-144-73-226.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 2281923451165959424; Tue, 12 Dec 2006 14:37:04 -0700 Original-To: "Emacs Devel" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= 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:63647 Archived-At: > > You initially spoke of limiting the "size" to the "window caption" >=20 > Perhaps in an alternate world; in this one, I said: "There's an old > hack in src/w32fns.c to avoid the user resizing an Emacs frame below > the minimum tracking size (else the user can, for example, make a > window showing only a fraction of the window caption, which looks > ugly)." That's textual from my message. My point was that you spoke of "size", not "height", and I naturally = assumed that you meant width as well as height. You said that you wanted = to avoid users resizing the frame to a fraction of the (size of the) = "window caption". I think my quoting was accurate in this world too ;-), = and my point was that, by "size", I thought you meant width too - in = particular, the width of the window caption. > > (frame title, I guess). >=20 > "Window caption" is the right term, according to the docs. I'm mostly > talking about Windows windows, not Emacs frames (even if they happen > to be the same in this case). >=20 > > I think now that you're speaking only of imposing a frame=20 > > height limit, not a width limit. >=20 > I'm talking about honoring the system defaults. >=20 > > I guess you're saying that a width limit is already imposed by=20 > > the system, and that is roughly the width of the icons used in=20 > > the title bar, plus maybe two title characters (at least that's=20 > > what I see in your image). Is that correct? >=20 > Yes. >=20 > > Do you just want to limit the height, not the width? >=20 > Both, thought limiting the width is redundant; Emacs already respects > SM_CXMINTRACK. I don't know what that means. Does it mean that you won't change the = minimum width or that the new minimum width ("size") would depend on the = current window caption? I don't want a frame with a long title to have a = different minimum width from one with a short title. > > If so, what is the height limit that you want to impose - one=20 > > frame-char height? >=20 > GetSystemMetrics (SM_CYMINTRACK), which is enough to show the=20 > window caption. >=20 > > Why? >=20 > What is the purpose of having a window like the one in the image I > sent in my previous message? Dunno. What is the purpose of prohibiting it, beyond ugliness? > > I still don't understand the problem you are trying to fix. >=20 > User-friendliness. Compatibility with the environment UI guidelines. Bof. Please elaborate, if it's really important. > > That's not a good reason to impose a size limitation, IMO. >=20 > The size limitation exists already. Apparently not in Emacs - your screenshot shows that. And the same thing = is true of Emacs going back to at least version 20 (which might be the = first Windows version). > > Someone might have a reason to shrink a frame to a tiny size,=20 > > perhaps in a way that is unrelated to character size. >=20 > And how do you pretend to do that currently with Emacs on Windows? Are > you suggesting *adding* machinery to allow sub-line frames with no > caption? You already did that yourself with Emacs on Windows, to create the = screenshot. I don't pretend to do anything; I'm not suggesting changing = anything. You are. > > Please describe the real problem. >=20 > Please, describe the use of such a window, and how do you pretend to > create and manipulate them. You're the one suggesting adding things, > AFAICS. I'm not suggesting changing or adding a single thing - you are. What is = the problem you are trying to fix? What's wrong with letting a user do = what you did with your frame? What does it hurt? There may be no obvious = purpose to it, but what does it hurt? > If someday we add support for such tiny windows, we can make an > exception. In fact, the existing code already *has* such exception for > the only windows (frames) that need it: tooltips. >=20 > > I have code that resizes frames, and it lets users set their=20 > > own minimum frame dimensions. I would not like Emacs to impose=20 > > some hard-coded minimum. >=20 > Does your code really give the user a way to make windows (frames) > smaller than the one in my sample image? On Windows? How do you do > that? No, and I never said it did. Why do you say "smaller"? I have no problem = with the frame in your screenshot. My impression is that you have a = problem with it. I thought you wanted to make the limits bigger than the = screenshot; it's not I who wants something smaller than that. My point in mentioning my code was that if an application wants to = impose a size limit, it can do so, possibly under user control, in Lisp. = You haven't given any reason to hard-code a larger size in C. Let = applications and users fix the limits, unless there is a good reason to = prevent that. > > If a given OS or window manager imposes a minimum, so be it,=20 > > but why make Emacs impose a minimum also? >=20 > Windows imposes a limit. We're respecting it. Badly. It works for > width, because the code does *not* try to adjust width. It fails for > height. I'm not adding a new feature, much as you seem intend on > presenting it as such. I'm proposing fixing a bug. Well, I don't see it as a bug. Beyond ugliness, you haven't said what = needs to be fixed. Frankly, if the size limit you propose is the same as your screen shot = in width, and it is the full height of the title bar in height, I don't = have a problem with that. It just means showing a full-height title bar, = instead of a partial-height one. No big deal. I don't see why you would make that change, but I don't really care, if = that's all you want to do. My main concern was to make sure you were not = going to impose a larger size limit than that (in particular, for the = width). If you had said from the beginning that you just wanted to show = the full _height_ of the title bar, I wouldn't have replied at all.