GNU bug report logs - #21415
25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

Previous Next

Full log

View this message in rfc822 format

From: Anders Lindgren <andlind <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Keith David Bershatsky <esq <at> lawlist.com>, 21415 <at> debbugs.gnu.org
Subject: bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame
Date: Tue, 20 Oct 2015 19:20:54 +0200

[Message part 1 (text/plain, inline)]

Ok, here comes a patch file for the "maximize" and "NSTRACE" rewrites, see
the file "emacs-commit-message.txt" for details. I would like you
(especially Keith, since Martin don't use OS X) to take a look at it before
I post in on emacs-devel and (unless people object) I commit it.

The rewrite became a bit larger than I originally expected since I realised
that the system to snap the frame size to the text grid was fundamentally
broken. It used a features called "SetResizeIncrements", where the
increments were set to the size of the current font. Unfortunately, once
the frame size got out of sync (e.g. by setting the frame size to a
specific pixel value) it remained out of sync. In addition, it interfered
with the maximization system.

The current implementation snaps the frame size to the text grid in a
callback function.

The patch below contains excluded code to maximize the frame the old way
using the system "zoom" function, and an excluded code section for a hybrid
maximize solution. Also, the code to restrict a frame to the screen height
is still present but excluded. Before I commit this to the archive I will
remove the excluded code, unless someone thinks that its worth while to
allow the user to configure this.

You can enable the NSTRACE system by uncommenting a line in nsterm.h, see
comments for detail.

In addition, I have included my own test file for frame maximization I
wrote to ensure that I didn't introduce any problems. Martin, if there are
anything in this you can use for your frame test file, feel free to use it.

Sincerely,
    Anders Lindgren


On Thu, Oct 15, 2015 at 12:00 PM, martin rudalics <rudalics <at> gmx.at> wrote:

> > I've got a quick question. I noticed that the OS X port behaves a bit
> > inconsistent when it comes to restricting a frame to the screen --
> > sometimes it is restricted in height, sometimes it's not. I would like to
> > make this more consistent, but I'm not sure in which direction I should
> go.
> >
> > How does the other terms (especially X11) behave? Does it restrict the
> > frame to be within the screen? If so, does it allow for the frame border
> to
> > be placed outside the screen?
>
> I suppose nobody can answer this question satisfactorily.  IMO good
> "systems" allow the frame to be placed anywhere.  And I usually have
> troubles only with window managers constraining placement.
>
> > What happens if the frame is first resized and then moved. Should the
> > resize truncate the height, even though the move would place the entire
> > frame inside the screen borders? Can a move and a resize be made
> atomically
> > (pixelwise)?
>
> For Emacs moving means to pass on coordinates to whoever is responsible.
> And Emacs itself never constrains the frame size (it must not get too
> small, though).
>
> > Personally, I'd prefer it there is no truncation. However, if it is, I
> > really would like to be able to allow the frame border to stretch outside
> > the screen, in order to really maximize the screen real estate.
>
> That's what most systems do AFAICT.  So if you can do that please go on.
>
> martin
>

[Message part 2 (text/html, inline)]

[maximize_and_trace.diff (text/plain, attachment)]

[anders-frame-test.el (application/octet-stream, attachment)]

[emacs-commit-messages.txt (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.