GNU bug report logs -
#25408
Remove Decorations Around Emacs Frame (Windows OS)
Previous Next
Full log
Message #161 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Apr 19, 2017 at 09:26:23AM +0200, martin rudalics wrote:
> If at this time I do within the just started Emacs
>
> (set-frame-parameter nil 'undecorated t)
>
> I get
>
> /home/martin/emacs-git/trunk/obj-ns/src/emacs: Uncaught exception NSInvalidArgumentException, reason: -[EmacsFSWindow setStyleMask:]: unrecognized selector sent to instance 0x30a37d0
It turns out that GNUStep doesn’t let you change the decorated state
of an existing window. It should be able to create a new undecorated
window.
> Setting the 'parent-frame' parameter of a frame has no impact, neither
> when I do it during frame creation not when doing it at any later time.
I believe it is setting the parent/child relationship, but in GNUStep
it doesn’t seem to mean the child moves with the parent. I think this
is a bug in GNUStep, but the behaviour isn’t documented yet, so I’m
not sure if it’s intentional.
The child will minimise and close with the parent and moving it to (0
0) will put it in the top left corner of the parent.
Except it doesn’t quite, because there’s a hard‐coded titlebar height
for GNUStep which is guaranteed to be wrong for every WM. At least I
think that’s what going on.
Z‐groups are working, but again in GNUStep it seems a bit hit and miss
as the frames seem to forget their state if you click on their
titlebars.
--
Alan Third
[0001-Add-new-frame-functionality-to-NS-port.patch (text/plain, attachment)]
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.