Minimum frame size in Windows

Minimum frame size in Windows

[Juanma Barranquero]

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).

However, the hack is not working. I propose fixing it with the
following straightforward patch.

                    /L/e/k/t/u


Index: src/w32fns.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32fns.c,v
retrieving revision 1.281
diff -u -2 -r1.281 w32fns.c
--- src/w32fns.c	1 Dec 2006 13:04:59 -0000	1.281
+++ src/w32fns.c	12 Dec 2006 16:18:44 -0000
@@ -3707,6 +3707,6 @@
 		   and Y positions as well.  */

-		lppos->cx -= wdiff;
-		lppos->cy -= hdiff;
+		lppos->cx = max (lppos->cx - wdiff, GetSystemMetrics (SM_CXMINTRACK));
+		lppos->cy = max (lppos->cy - hdiff, GetSystemMetrics (SM_CYMINTRACK));

  		if (wp.showCmd != SW_SHOWMAXIMIZED
@@ -3732,7 +3732,4 @@

     case WM_GETMINMAXINFO:
-      /* Hack to correct bug that allows Emacs frames to be resized
-	 below the Minimum Tracking Size.  */
-      ((LPMINMAXINFO) lParam)->ptMinTrackSize.y++;
       /* Hack to allow resizing the Emacs frame above the screen size.
 	 Note that Windows 9x limits coordinates to 16-bits.  */

RE: Minimum frame size in Windows

[Drew Adams]

> 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).
> 
> However, the hack is not working. I propose fixing it with the
> following straightforward patch.

Perhaps I don't understand correctly, but if this prevents users or Lisp code from making frames smaller than the frame title, I am 100% against it.

I am probably against preventing users or Lisp code resizing a frame in _any_ way, especially in C code that cannot easily be overridden in Lisp. Please, hands off my ugly frames ;-).

Re: Minimum frame size in Windows

[Lennart Borgman]

Drew Adams wrote:
>> 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).
>>
>> However, the hack is not working. I propose fixing it with the
>> following straightforward patch.
>>     
>
> Perhaps I don't understand correctly, but if this prevents users or Lisp code from making frames smaller than the frame title, I am 100% against it.
>
> I am probably against preventing users or Lisp code resizing a frame in _any_ way, especially in C code that cannot easily be overridden in Lisp. Please, hands off my ugly frames ;-).
>   

No, Juanma is only AFAICS trying to avoid making a frame window smaller 
than the systems limits to window sizes in a simple way when adjusting 
the size to fit whole characters.


Looks ok to me.

Re: Minimum frame size in Windows

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

On 12/12/06, Drew Adams <drew.adams@oracle.com> wrote:

> Perhaps I don't understand correctly, but if this prevents users or Lisp code from making frames smaller than the frame title, I am 100% against it.

On Windows, there's a(n overridable) system limit for how small a
window can be. Currently Emacs half-supports it: you can not do a
window arbitrarily small by resizing it, but you can do it as wide as
the system limit, and (I think) as hight as a line in the default
font, which often is less than the window caption (see the attached
image).

That's why I'm trying to avoid.

Do you have an use for Emacs frames less than this size? How do you
avoid the caption?

                    /L/e/k/t/u

[-- Attachment #2: half.png --]
[-- Type: image/png, Size: 3916 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

RE: Minimum frame size in Windows

[Drew Adams]

> > Perhaps I don't understand correctly, but if this prevents 
> > users or Lisp code from making frames smaller than the frame 
> > title, I am 100% against it.
> 
> On Windows, there's a(n overridable) system limit for how small a
> window can be. Currently Emacs half-supports it: you can not do a
> window arbitrarily small by resizing it, but you can do it as wide as
> the system limit, and (I think) as hight as a line in the default
> font, which often is less than the window caption (see the attached
> image). That's why I'm trying to avoid.
> 
> Do you have an use for Emacs frames less than this size? How do you
> avoid the caption?

Thanks for the explanation. 

You initially spoke of limiting the "size" to the "window caption" (frame title, I guess). I thought you meant width too. Please do not impose a width limit, especially one that depends on the width of the current frame title. That's the main objection I had.

I think now that you're speaking only of imposing a frame height limit, not a width limit. I guess you're saying that a width limit is already imposed by the system, and that is roughly the width of the icons used in the title bar, plus maybe two title characters (at least that's what I see in your image). Is that correct? Do you just want to limit the height, not the width? If so, what is the height limit that you want to impose - one frame-char height? Why? 

I still don't understand the problem you are trying to fix. You mention only ugliness. That's not a good reason to impose a size limitation, IMO. Someone might have a reason to shrink a frame to a tiny size, perhaps in a way that is unrelated to character size. And people who don't want to shrink to such a tiny size just won't do it. What does it hurt to allow this? What is the real need for such a change? Did you run into a problem and somehow ended up with a frame like the one you sent an image of? Please describe the real problem.

If it aint broke don't fix it, please. (Or, as someone here is wont to say, "No one has ever complained about that before" ;-).)

I have code that resizes frames, and it lets users set their own minimum frame dimensions. I would not like Emacs to impose some hard-coded minimum. If a given OS or window manager imposes a minimum, so be it, but why make Emacs impose a minimum also?

Re: Minimum frame size in Windows

[Juanma Barranquero]

On 12/12/06, Drew Adams <drew.adams@oracle.com> wrote:

> You initially spoke of limiting the "size" to the "window caption"

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.

> (frame title, I guess).

"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).

> I think now that you're speaking only of imposing a frame height limit, not a width limit.

I'm talking about honoring the system defaults.

> I guess you're saying that a width limit is already imposed by the system, and that is roughly the width of the icons used in the title bar, plus maybe two title characters (at least that's what I see in your image). Is that correct?

Yes.

> Do you just want to limit the height, not the width?

Both, thought limiting the width is redundant; Emacs already respects
SM_CXMINTRACK.

> If so, what is the height limit that you want to impose - one frame-char height?

GetSystemMetrics (SM_CYMINTRACK), which is enough to show the window caption.

> Why?

What is the purpose of having a window like the one in the image I
sent in my previous message?

> I still don't understand the problem you are trying to fix.

User-friendliness. Compatibility with the environment UI guidelines.

> That's not a good reason to impose a size limitation, IMO.

The size limitation exists already.

> Someone might have a reason to shrink a frame to a tiny size, perhaps in a way that is unrelated to character size.

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?

> Please describe the real problem.

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.

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.

> I have code that resizes frames, and it lets users set their own minimum frame dimensions. I would not like Emacs to impose some hard-coded minimum.

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?

> If a given OS or window manager imposes a minimum, so be it, but why make Emacs impose a minimum also?

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.

                    /L/e/k/t/u

RE: Minimum frame size in Windows

[Drew Adams]

> > You initially spoke of limiting the "size" to the "window caption"
> 
> 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).
> 
> "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).
> 
> > I think now that you're speaking only of imposing a frame 
> > height limit, not a width limit.
> 
> I'm talking about honoring the system defaults.
> 
> > I guess you're saying that a width limit is already imposed by 
> > the system, and that is roughly the width of the icons used in 
> > the title bar, plus maybe two title characters (at least that's 
> > what I see in your image). Is that correct?
> 
> Yes.
> 
> > Do you just want to limit the height, not the width?
> 
> 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 
> > frame-char height?
> 
> GetSystemMetrics (SM_CYMINTRACK), which is enough to show the 
> window caption.
> 
> > Why?
> 
> 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.
> 
> 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.
> 
> 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, 
> > perhaps in a way that is unrelated to character size.
> 
> 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.
> 
> 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.
> 
> > I have code that resizes frames, and it lets users set their 
> > own minimum frame dimensions. I would not like Emacs to impose 
> > some hard-coded minimum.
> 
> 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, 
> > but why make Emacs impose a minimum also?
> 
> 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.

Re: Minimum frame size in Windows

[Juanma Barranquero]

On 12/12/06, Drew Adams <drew.adams@oracle.com> wrote:

> 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.

That's right. But it's not me who's proposing it. It's Windows.

> 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.

I already said I wanted Emacs to respect the tracking size.

                    /L/e/k/t/u

Re: Minimum frame size in Windows

[Juanma Barranquero]

On 12/12/06, Drew Adams <drew.adams@oracle.com> wrote:

> My point was that you spoke of "size", not "height", and I naturally assumed that you meant width as well as height.

I mean it.

> You said that you wanted to avoid users resizing the frame to a
> fraction of the (size of the) "window caption".

No, I *didn't*. I talked about respecting the tracking size, and then
I put the current behavior as an example of the result of not
respecting it. I've never said: "let's force the frame to be no
smaller than the caption, or the caption's title." I've said (quite a
few times already): "let's force the frame to respect the tracking
size".

> in particular, the width of the window caption.

I get the impression you interpret "window caption" as the title text
of the window. I'm referring to the UI element consisting of an small
icon, a title (totally or partially visible) and minimize, maximize
and close buttons (in the window style used by Emacs).

> 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.

The length of the text in the caption is irrelevant for tracking size purposes.

> Dunno. What is the purpose of prohibiting it, beyond ugliness?

Consistency with other Windows apps. Pick a corner of your Explorer or
Firefox window, and drag it to reduce the window. You'll hit a wall.
Bingo! Welcome to the tracking size limit.

> Bof. Please elaborate, if it's really important.

Consistency is important. It can be skipped, if there's a reason.

> Apparently not in Emacs - your screenshot shows that.

No, my screenshot shows a bug. Read the code. In my patch I removed
lines that specifically talk about *respecting* the tracking size.

The current code does not intend to be agnostic respect to the frame
size; it does quite a few computations with it. Why aren't you
campaigning against the full-lines limitation? That Emacs currently
allows a window of half a caption's height is a bug.

> You already did that yourself with Emacs on Windows, to create
> the screenshot.

No, I grabbed one corner of the Emacs window (frame) and dragged it
(on an unpatched Emacs, of course) till it stopped.

> I don't pretend to do anything; I'm not suggesting changing
> anything. You are.

You pretend to keep a bug for some future, hypothetical use of the bug
as a feature.

> What's wrong with letting a user do what you did with your
> frame? What does it hurt?

Consistency of UI.

> No, and I never said it did. Why do you say "smaller"?

Because that, with the full caption instead of a fragment of it, it's
the default tracking size! And you're insistent of letting the user
create frames past down that limit!

> 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.

I don't know how you could, from lisp, create a frame smaller than that.

> You haven't given any reason to hard-code a larger size in C.

If you would have taken a look at my code you'd seen there's no
hardcoded limit. GetSystemMetrics() returns the system defaults.

> 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.

Frankly, I get the impression you jumped to fight my patch without
even taking the time to understand what was I proposing and what was I
trying to fix.

                    /L/e/k/t/u

RE: Minimum frame size in Windows

[Drew Adams]

> Frankly, I get the impression you jumped to fight my patch without
> even taking the time to understand what was I proposing and what was I
> trying to fix.

I tried to understand you, but I had some difficulty. Now that I've googled for "tracking size" I understand better what you intend. I have no problem with it.

I misunderstood you to be saying that the minimum size (including width) should not be less than the "window caption", which I took to be the title text.

Sorry for any misunderstanding.

Re: Minimum frame size in Windows

[Juanma Barranquero]

On 12/12/06, Drew Adams <drew.adams@oracle.com> wrote:

> I tried to understand you, but I had some difficulty.

I know my English is broken, but I think my initial message already
contained the required info, in a relatively precise (and perhaps
concise) way...

> Now that I've googled for "tracking size" I understand better
> what you intend. I have no problem with it.

I'm glad to hear it :)

                    /L/e/k/t/u