GNU bug report logs - #25408
Remove Decorations Around Emacs Frame (Windows OS)

Previous Next

Package: emacs;

Reported by: Arthur Miller <arthur.miller.no1 <at> gmail.com>

Date: Mon, 9 Jan 2017 22:21:02 UTC

Severity: wishlist

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Alan Third <alan <at> idiocy.org>
Cc: Arthur Miller <arthur.miller.no1 <at> gmail.com>, 25408 <at> debbugs.gnu.org, Clément Pit--Claudel <clement.pit <at> gmail.com>
Subject: bug#25408: Remove Decorations Around Emacs Frame (Windows OS)
Date: Thu, 13 Apr 2017 09:10:26 +0200
>> When can you remove the decorations?  Does it flicker when you do that?
>
> I mean, it *can* resize after I remove the decorations.

I wanted to know "when" in the sense of "what do you have to wait for"
to remove the decorations?  Can you send two requests in a row - a first
one to create a decorated frame and a second one to remove the
decorations - or do you have to wait for a response for the first
request before issuing the second one.

> There’s no
> flickering, it’s all quite smooth.

Then I see no problems with an approach that makes the frame initially
decorated and removes the decorations ASAP.

> The actual macOS window resizes, but the contents of that window
> (Emacs) don’t. I’ve attached a screenshot that will hopefully explain
> it better.
>
> If I add decorations and remove them again:
>
>      (set-frame-parameter nil 'undecorated nil)
>      (set-frame-parameter nil 'undecorated t)
>
> Then I can resize it fine. So it seems like the decorations are adding
> something that allows the resize to work.
>
> I’ve tried turning on NSTRACE, but the output looks identical whether
> resizing works or not.

Is this in windowDidResize or windowWillResize?  I have no idea how the
NS API works.  But if the redecorate/reundecorate approach works well, I
wouldn't care too much.

Can you look also into three other things I added:

- Provide a `move-frame-functions' hook.

- Provide "frame restacking" which should work via orderWindow.  I
  suppose NS has no equivalent for z-groups.

- Provide "child frames" which should work via parentWindow.

I don't know whether NS child windows always behave like NS "drawers" or
may also occlude the parent frame like under X or Windows.  Eventually
I'd like to have them both (like Wayland's subsurfaces if I understand
them correctly).  Drawers look like a pain when you are in fullscreen
mode - IIUC there's no way to open them "into" a fullscreen frame.
X/Windows child windows are annoying when you are in a normal, fairly
small frame where they get clipped too easily.

Thanks, martin





This bug report was last modified 7 years and 348 days ago.

Previous Next


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