all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Juanma Barranquero" <lekktu@gmail.com>
Cc: Emacs Devel <emacs-devel@gnu.org>
Subject: Re: Minimum frame size in Windows
Date: Tue, 12 Dec 2006 23:14:34 +0100	[thread overview]
Message-ID: <f7ccd24b0612121414n77f5cb8ehfb9e545eeab3ca5f@mail.gmail.com> (raw)
In-Reply-To: <EIENLHALHGIMHGDOLMIMOEHBCNAA.drew.adams@oracle.com>

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

  parent reply	other threads:[~2006-12-12 22:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-12 16:36 Minimum frame size in Windows Juanma Barranquero
2006-12-12 16:42 ` Drew Adams
2006-12-12 17:14   ` Lennart Borgman
2006-12-12 17:22   ` Juanma Barranquero
2006-12-12 17:56     ` Drew Adams
2006-12-12 19:39       ` Juanma Barranquero
2006-12-12 21:37         ` Drew Adams
2006-12-12 21:54           ` Juanma Barranquero
2006-12-12 22:14           ` Juanma Barranquero [this message]
2006-12-12 22:26             ` Drew Adams
2006-12-12 22:34               ` Juanma Barranquero

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f7ccd24b0612121414n77f5cb8ehfb9e545eeab3ca5f@mail.gmail.com \
    --to=lekktu@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.