[feat. discussion] Add an explicit `always_on_top` configuration option and launch option about kitty

[kovidgoyal]

OK, I can accept this as an action and additional value to --start-as.
And yes dont change the floating implementation, create a new window
attribute for it, named alwaysontop or something similar and implement
it in the cocoa backend. The wayland one will remain unimplemented,
given the general feature poorness of wayland I doubt it's implementable
there. The X11 implementation can just set the on top window hint just as
the floating one does now.

[kovidgoyal]

On wayland _glfwPlatformSetWindowFloating is unimplemented. On X11 it sets _NET_WM_STATE_ABOVE which is a hint that the window should be above most other windows. For reference see: https://specifications.freedesktop.org/wm-spec/wm-spec-1.4.html#STACKINGORDER However what effect it actually has is window manager dependent. On macOS it sets the window level to floating which means the window will be below all non floating windows. I see in your fork you want to change that to status level which puts it above all none status windows. But there are alos some collection level changes What effect do they have?

And more generally, I dont think this should be a config option. There is no reason to expect it to apply to all kitty OS windows. It would instead be an action that can be mapped and that toggles the state and possibly also a CLI option under --start-as. The action would need major caveats that its effect is advisory only and requires co-operation from the window manager.

[dljsjr]

I see in your fork you want to change that to status level which puts it above all none status windows

Having the NSWindowLevel set to Status is required for the window to be truly on top of anything in its space, including the Dock and global Menu Bar if either of them aren't set to auto-hide. NSFloatingWindowLevel doesn't allow you to do that.

That said, having typed it out now, the better implementation is probably not overriding the intent of the GLFW floating bit; instead I should probably propagate the always-on-top request in to the Cocoa wrapper and branch on that.

---

But there are alos some collection level changes What effect do they have?

The values for that bitmask can be found here: https://developer.apple.com/documentation/appkit/nswindow/collectionbehavior

They control how windows will behave under the various macOS features that will "collect" windows for you, such as Mission Control/Expose, Native Full Screen, across Spaces, and in Stage Manager.

• canJoinAllApplications allows the window to be shown without switching away from the active app group when in Stage Manager, and also implies fullScreenAuxiliary for displaying over top of native Full Screen windows.
• canJoinAllSpaces means that the window can show on any Space, instead of taking you back to the Space where the window is assigned whenever it gains focus
• transient means that the window doesn't show when activating Mission Control, and that it doesn't belong to a Space
• IgnoresCycle excludes the window from the window cycling functionality (Cmd+`)

So the Collection Behaviors are used to allow for creating a truly always-on-top window that can display over a full screen app, stage manager group, across any Space, and while also not participating in window cycling or Mission Control.

---

And more generally, I dont think this should be a config option. There is no reason to expect it to apply to all kitty OS windows. It would instead be an action that can be mapped and that toggles the state and possibly also a CLI option under --start-as. The action would need major caveats that its effect is advisory only and requires co-operation from the window manager.

Agreed that this probably makes more sense than having it as a config. Thanks for the feedback.

[kovidgoyal]

Closing, feel free to continue discussion in a PR.