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

[martin rudalics]

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