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

[Anders Lindgren]

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

maximize_and_trace.diff
Description: Text document

anders-frame-test.el
Description: Binary data

emacs-commit-messages.txt
Description: Text document