Subject: bug#25408: Remove Decorations Around Emacs Frame (Windows OS)

From: martin rudalics <[email-masked]>
Date: Sat, 15 Apr 2017 21:39:32 +0200

> If I understand your description right, there is a direct equivalent
 > for z‐groups: levels. Here’s Apple’s documentation on them:
 >
 >> The levels you typically use are: NSNormalWindowLevel, which
 >> specifies the default level; NSFloatingWindowLevel, which specifies
 >> the level for floating palettes; and NSScreenSaverWindowLevel, which
 >> specifies the level for a screen saver window. You might also use
 >> NSStatusWindowLevel for a status window, or NSModalPanelWindowLevel
 >> for a modal panel.

Maybe the last two could be used for emulating the 'above' group.  It
would be nice to have a common interface for that.

 > This is in addition to the basic ‘layers’, which orderWindow deals
 > with and which only affects windows in the same ‘level’.

This should conform with what we have on X and Windows.

 > It appears that a child window in NS is just a normal window which
 > moves and closes with its parent. So I think that means it’s more like
 > X’s child windows, except they don’t get clipped at the parent
 > window’s edges. They can also end up below the parent window.

It sounds like NS can do more than Windows and X here.  The clipping
issue is a nuisance.  Could you try to create one and play around with
it a bit?

 > I think this is probably what we want, for now at least.

Certainly.

 > FYI: there are also drawers and something called sheets, which appear
 > to be some sort of special modal drawer type thing used for error
 > messages and such.
 >
 > I’ve pretty much got the undecorated frames sorted with only one major
 > bug I’m aware of when the frame is nearly the full height of the
 > screen. I think I may have to ask Anders about that as I can’t
 > understand the code that keeps the frame on‐screen, and I think it may
 > be the culprit.

On X decorating an undecorated maximized frame can be funny too.  There
may be no visible change.

martin