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

Previous Next

Full log

Message #302 received at 21415 <at> debbugs.gnu.org (full text, mbox):

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

> 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

Previous Next

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