bug#24579: [PATCH] borderless windows on OS X

[martin rudalics <rudalics@gmx.at>]

 >> (1) Is there a way to mix behaviors in one and the same session - that
 >> is have at the same time a window with a title bar and one without?
 >> It's possible under X and Windows as can be seen with tooltip frames.
 >
 > Yes, because as implemented the variable only affects new frames, so
 > you can switch it on and off as you create frames to get both styles.
 > Thus, it could be a frame parameter as well. I didn't do it this way
 > because I personally want it to be a global setting and because I
 > didn't see the existing window creation code looking at the frame
 > parameter alist and I didn't look around the file much to get a bigger
 > picture of how it works.

So once installed, binding your variable around ‘make-frame’ calls
should do the trick, I presume.

 >> (2) Is there an option to draw borders and, if so, borders of different
 >> width on a borderless frame?  Latter are available via X but not on
 >> Windows.
 >
 > Yes, I believe that the
 >
 > setContentBorderThickness:forEdge:
 >
 > function on the win object would let you do that, but I haven't test
 > that. I know that iTerm2's title-less option gives the ability to add
 > a border, but I worry it is implement with a custom renderer.
 >
 > https://developer.apple.com/reference/appkit/nswindow/1419541-setcontentborderthickness?language=objc
 >

In my experience, completely border-less frames are disorienting unless
they completely fill the display.

 >> (3) IIUC setting your option does not toggle titles/borders on existing
 >> frames.  Would it be possible to do so?  We could do that on Windows but
 >> it seems impossible with GNU/Linux window managers.
 >
 > It is possible to do that with [win setStyleMask:
 > NSBorderlessWindowMask], so it would be conceivable to add some
 > functions that would flip that setting on real frames. Although, I
 > don't see a way to go from an Emacs frame structure to the window
 > object. So, this seems like it would be a big patch (because you'd
 > want to do it in as cross-platform a way as possible)

It wouldn't be done anyway because it would fail on GNU/Linux.

 > and different
 > than this one, so I hope the current patch is judged independently.

I cannot test this because I don't use OS X.  So anyone who is able to
judge this, please disregard my questions and the corresponding answers.

 >> Thanks again, martin
 >
 > FWIW, I am not an OS X developer, so I don't know all the ins-and-outs of this.
 >
 > My preference would be for this patch to go in if someone isn't going
 > to immediately do the frame parameter thing, because I don't have the
 > bandwidth to do it, I don't think.

No need for the frame parameter thing.  It's more distracting than
doing any good.

Thanks for answering, martin