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: Alan Third <alan <at> idiocy.org>
To: martin rudalics <rudalics <at> gmx.at>
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 11:30:26 +0100
On Thu, Apr 13, 2017 at 09:10:26AM +0200, martin rudalics wrote:
> >> 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.

I’ve worked it out: the toolbar is considered a ‘decoration’ by Cocoa,
so it is automatically removed when I change a frame to undecorated.
However, when I create a new undecorated frame the frame redrawing
code waits for the toolbar to be drawn, which will never happen.

I think this gives me two options:

  1. Get Emacs to disable the toolbar when switching to undecorated
     frames.

  2. Use a different method of removing the titlebar when the toolbar
     is enabled than when the toolbar is disabled. This option will
     only work in macOS 10.11 and above.

Option 1 seems preferable to me, although we could add option 2 later.

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

I don’t know enough about NS to be able to answer this. I’ll give it a
go and see what happens.
-- 
Alan Third




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

Previous Next


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