kitty: Also offer the X11 version

[EvanCarroll (Evan Carroll)]

In the FAQ it says,

You may find some ports that link with some system libraries. Some of these are intentional, such as in cases where the MacPorts version is missing some crucial functionality (e.g. ports that need Kerberos support use the Mac OS X-supplied library, not the MacPorts one). In other cases these are bugs in the relevant ports, and tickets should be filed so it can be corrected.

I believe Kitty is one such port,

​https://apple.stackexchange.com/q/354720/76955

[EvanCarroll (Evan Carroll)]

Ideally, I would be able to run it under i3, and not have it open up a native window.

[ryandesign (Ryan Carsten Schmidt)]

The situation described in the FAQ is different from the one you are experiencing with Kitty.

The FAQ entry describes this situation: a port links with, say, /usr/lib/libz.1.dylib. This is undesirable: we want it to link with /opt/local/lib/libz.1.dylib instead, because the MacPorts copy of zlib is newer than the macOS copy and is updated more frequently.

The situation with Kitty is that Kitty, or at least the part of it that we build in the kitty port, is a macOS Cocoa application, but you would like it to be an X11 program. It looks like Kitty is cross-platform and does use X11 on non-Mac operating systems, so it seems plausible that the X11 version could also be compiled on macOS. If so, we could potentially offer the X11 version of kitty alongside the macOS Cocoa version, perhaps by defining an +x11 variant in the kitty port, or by offering a separate kitty-x11 (sub)port. I don't believe anybody has attempted to do that yet.

[EvanCarroll (Evan Carroll)]

Is there a convention or rule to put cocoa apps in /Applications (as compared to /opt/)

[ryandesign (Ryan Carsten Schmidt)]

Certainly, Cocoa applications go in ${applications_dir} (which is usually /Applications/MacPorts), while command line programs and X11 programs go in ${prefix}/bin (which is usually /opt/local/bin).