bug#25408: Remove Decorations Around Emacs Frame (NS port)

[Alan Third <alan@idiocy.org>]

On Mon, Apr 17, 2017 at 05:43:57PM +0200, martin rudalics wrote:
> Looks good to me.  I suppose though this won't work with GNUStep so I
> can't try it.  Two remarks below.

I’m not sure about the decoration stuff, but I think, from a quick
glance at the GNUStep docs, the parent/child window stuff should work.

I’ll try and build it under GNUStep at some point to check it works.
I’ve got a GNU/Linux virtual machine around here somewhere...

> > + * Set frame F's `undecorated' parameter.  If non-nil, F's window-system
> > + * window is drawn without decorations, title, minimize/maximize boxes
> > + * and external borders.
> 
> I suppose you want to mention the removal of the toolbar here.  If so,
> we'll have to mention that in the manual as well.

Yes, good point.

> When you re-add the decorations, does the inner frame move or are
> the decorations drawn around an unmoved inner frame?

There are only two situations where the inner frame will move. The
first is if you have the toolbar enabled, when you re‐add the
decorations the toolbar reappears and slides the rest of the frame
down. (Similarly when you remove the toolbar the rest of the frame
slides up.) The other is if the titlebar would be behind the menubar,
then the system moves the whole frame down just enough to keep it
completely visible.

> > + * A child frame's `left' and `top' parameters specify positions
> > + * relative to the top-left corner of its parent frame's native
> > + * rectangle.
> 
> Does the above hold for NS?  Does a (set-frame-position child 0 0)
> really put child in the upper left corner of its parent?

Most of the time spent implementing the child/parent frames was
getting that working right, so yes, it does.

Now, one thing that may be wrong is that (0 0) is actually the very
top, including the titlebar. I could probably fix that if it’s not
right just by offsetting by the height of the titlebar.

-- 
Alan Third