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

[martin rudalics]

> I forgot that this bug is still open. Is it waiting for me to finish
> up the NS stuff?

By no means.  You've already accomplished much more than I would have
expected.  I still want to check in the ‘no-special-glyphs’ parameter
code mentioned elsewhere in this thread.  Then I intend to close this
bug.

>>> Should I look into no-focus-on-map and no-accept-focus too?
>>
>> That would be fine.  There's also the 'skip-taskbar' parameter but I
>> have no idea whether NS allows that and whether NS provides Alt-tabbing.
>
> no-accept-focus is done, but no-focus-on-map is harder. I believe I
> can get a new frame to not be focused on creation, but I don’t see any
> way to prevent a minimized frame from becoming focused when
> unminimized.

Don't worry.  Unminimizing is different from mapping.  The former works
on already mapped frames only, the latter on invisible frames only.
"on-map" stands for "on making the frame visible" which might happen
some time after the frame was created.  Once visible you cannot map the
frame until you make it invisible again.

Alt-tabbing and unminimizing OTOH work on visible frames only, you
cannot really unminimize an invisible window (although the window
manager might remember the requested fullscreen status somewhere and
later, when it makes the window visible, apply that state).

‘no-focus-on-map’ behaves well for all platforms and builds I tried so
far.  It would be nice to have it for NS builds too.  So all that is
afforded by ‘no-focus-on-map’ is that, whenever a frame changes from the
invisible to the visible state, it does not get focus.

> macOS has alt‐tabbing between applications, but also alt‐` switches
> between application windows. I haven’t yet found a way to disable
> this.

There's certainly no need to do that.  I wouldn't even know how to type
alt-` with my keyboard layout.

> FWIW, no-accept-focus, as implemented, prevents a frame from *ever*
> accepting focus (although it can still accept input, which is
> strange!). Rereading your description makes me wonder if I’ve done
> that wrong and the current behaviour is closer to no-accept-focus,
> no-focus-on-map and skip-taskbar all being on?

‘no-accept-focus’ is not overly dear to me.  I provided it because it
works out of the box on GNU Linux.  But the workaround I wrote for
Windows is very harsh and I don't recommend it.  The idea is to provide
a behavior similar to tooltips - you cannot focus a tooltip window -
with something like "but you can still focus it via C-x 5 o, if you
need to".

> I’m not sure I can do it any other way, though.

Never mind.  If it has some very special behavior and you feel like it,
add a remark about it in the Elisp documentation.

>> And please have a look into the Elisp manual: Maybe you find something
>> worth mentioning (the fact that removing decorations removes the tool
>> bar should certainly go there).

This one still stupefies me because it's a deviation from the other
builds.  It certainly should be documented.  Did you document that a
fullscreen NS screen doesn't have a toolbar either?

BTW, I meanwhile wrote some code to resize and move undecorated frames
with the mouse.  For this purpose I need some mouse pointers indicating
that a frame corner (not a frame edge) can be dragged.  Under X I use
XC_top_left_corner, XC_top_right_corner, ...  On Windows I use the
IDC_SIZENWSE and IDC_SIZENESW arrows.  I have not found any equivalent
for NS.  How does NS indicate that the corner of a decorated frame can
be dragged when the mouse is over it?

Thanks for all your work, martin