updated macOS cocoa backend to correctly render instead of sdl2/3

[johncurley]

So it turns out the reason the sdl2 libraries were needed was that the code wasn't calling the native cocoa backend. I've updated and tested the code to work with the native libraries and fixed a few bugs that were present because of that, now alleviating the need for sdl2 unless explicitly set. Sorry about that, a bit embarrassing.

[dpjudas]

Thanks for the pull request, but could you split it into multiple requests? This one is doing a lot of different unrelated stuff. As it is right now I can't merge it as some things I don't agree with (at least without further discussion), while other things are okay and could be merged.

Things in this pull request:

1. Changes to the general build system (CMakeLists.txt) for when SDL is required and when its not.

2. Changes to how Linux finds the system UI font. This part in particular I don't agree with as asking for a 'sans-serif' font on the system does not give you the user UI font. The core of the problem here is that Linux doesn't have a standardized way - that's why its asking gtk first before using fontconfig to locate the font. While I can understand the desire to drop the gtk dependency, the changes here actually returns the wrong answer as I understand it. I'd be happy to further discuss how to improve this, or make gtk conditional (preferably via dynamic linking or alternatively via cmake options), the changes as seen here is not IMHO better than what its doing today.

3. Removing misc unused variables that has nothing to do with anything else in the PR (TrueTypeFont classes). I assume this was motivated by warning messages? In any case, the problem with the TTF changes is that it removes information that was otherwise present in the source code. While this information can be retrieved from the OpenType spec, seeing it in the source code is more helpful IMHO when you see it skipping some fields in TTF tables. The variable name conveys information about what was skipped/ignored.

4. Changes to Widget trying to prevent circular references and then silently catching such situations and ignoring it. It should not be possible to have a circular widget reference without API misuse or some deeper bug in how it handles its widget tree. If this is to prevent user error when adding widgets, the check should be performed during widget attachment, not when MapFrom is called.

5. macOS system font retrieval changes. Using a hard coded list of font names as a last resort effort if all else failed is okayish, I suppose. I'm wondering when this situation happens in practice though. When can't macOS get a file path to the system UI font?

6. Fix a memory leak due to missing TTFDataBuffer virtual destructor.

7. Misc scope groups added ({ and }) to things otherwise untouched (Canvas, ListView, TabBar). Splitting a variable into 3 variables in ListView. I assume this was because you looked at something in those classes, but since nothing actual was changed that's basically just noise in the PR.

8. TextEdit out of bounds checks.

9. Cocoa display backend improvements.

10. Fix DisplayBackend::TryCreateBackend so it actually attempts to create the cocoa backend (what the PR officially states that it does).

That is a lot of different things to include into one big mega PR. While there's plenty of stuff in it that's good and I'd love to merge, at the same time there are blocking parts (Widget class changes and Linux system font lookup in particular) that prevents me from simply pressing the merge button. We have to find a solution to this, or alternatively split it into multiple pull requests where most of them can then merged and rest be discussed.

[johncurley]

Yes, you are right in that the codebase is not atomic and also has a lot of opinionated changes that will need to be modularized or removed before a pull request.

1. I found this was necessary to avoid pulling sdl2 in for testing that the build was actually native cocoa. Though I can probably undo these changes, there's no problem compiling both at this time until the cocoa build is tested.

2. I forget the reason for this, I think it failed on a Linux compilation for some reason but I'll revert it.

3. Yes these were warning messages but really shouldn't have been touched.

4. This was probably me working on trying to fix why the widgets were not responding to certain events. It turned out that I hadn't registered the window correctly as a desktop application and input was piped to the terminal. I'll remove this.

5. For some reason the NSFont code couldn't detect the system font due to it being embedded. There's probably a more elegant solution to this though that I'll look into, especially removal of the hard coded strings.

6. I think this was necessary to compile, but maybe it was caused by my earlier removal of the variables?

7. Yeah, this was related to 4. But it shouldn't be in there.

8. Again, 4.

9. Necessary for PR.

10. Code initialization as noted earlier. I'll fix up this PR anyway and remove what is unnecessary. It really is a mess and shouldn't have been released in this fashion.

[johncurley]

Okay changes made, let me know if I've missed anything or you need further modifications. I'll try to be more careful in future with commits, to try commit atomically.

I did notice that I tried compiling your latest ZVulkan library and glslang was complaining that the minimum macOS build version was 10.15. A few of the features I am using for macOS require 10.15 so I wonder if in the near future/next version it gets bumped to 10.15 minimum?

Also in terms of the shader translation library, I think for now I'll stick to glsl->SPIR-V->msl and look into cross compiling from glslang to spirv-cross and potentially hlsl(maybe the windows application can compile it for dxc so the shader translator just has to supply hlsl).

Not sure yet, I think I'll just try get metal working for now. But I appreciate all the guidance and help so far along with this journey and the patience.

[johncurley]

In terms of the GTK code, it was run in a headless environment for testing, I wonder if we can create some kind of better loader for Linux that will detect on all desktop environments what fonts are available and conditionally load them? I'm going to pick up an old PC, probably a 6th gen Intel or something for testing and also Linux/Haiku work.

In terms of the incompatibility with macOS 10.13, maybe GZDoom 4.15 could be the last version to support this, then we can bump compatibility up to 10.15 to support modern graphical functionality. However allowing 4.15 to support 10.13 would still allow a lot of modern functionality for that OS and older Macs that can still use Metal 2. However there's no reason to have an ancient OS hobble further developments of the engine in the near future. I was thinking a compatibility fork but a better solution would be to just recommend older builds for unsupported OS's. Since the code is open anyway, people can always fork and support whatever they like if they feel the support is warranted. Even macOS 12.7.6 what I'm on is ancient by macOS standards and hopefully I can get an ARM based machine soon.

[dpjudas]

Thanks for adjusting the PR.

About the gtk thing, I can change it so it dynamically loads it so its not a hard dependency. If gtk is not found we can use the fallback strategy you had, asking fontconfig to give us a generic sans-serif font to at least have something.

Our problem with Linux in general is that nothing is actually standardized as far as I know. Essentially the "system UI font" depends on the desktop environment you're using. If that is KDE then it uses whatever they do. If its Gnome it uses Gtk's method. If windowmaker is used, or who knows what else, there might not even be a formal way to query for it.

The current implementation is based on the assumption that a lot of Linux applications already use Gtk. Because of that, even if the desktop environment is something different, a good distro should attempt to keep all the various popular app toolkits in sync with what you pick in the (desktop environment specific) control panel. That's just an assumption of mine, I haven't verified if that's what the distros do, but its the best I got.

In a perfect world we'd have code for each of the popular desktop environments to find the system UI font. However, even if we did have that, we'd also need to know which one is active. Simply locating gtk on the system is actually not a guarantee that this is the desktop environment actively being used.

About your questions for zvulkan, I don't have any problems with bumping the macOS version in CMakeLists.txt if that solves some problems for you.

Having Direct3D HLSL translation is mostly a nice-to-have feature. Vulkan support is strong on anything else than Apple hardware. It is not like in the old days with OpenGL where Intel had very broken drivers.

[johncurley]

Hey dpjudas,

I wonder for the font configuration we could cycle through the most popular widget toolkit detection dynamically(Qt based and GTK) then falling back to font_config, finally if all else fails just loading a bundled font. This might help for other OS's such as the BSD's in the near future as well.

I agree about Vulkan being the premier and only necessary renderer on all platforms beside MacOS(I like native if possible). Especially with the advent of Valve's new Steam hardware which is Vulkan based, making the api more popular than ever. I was just thinking HLSL since apparently it's a very popular language and might help some developers port their mods to the engine coming from a Windows background since HLSL-SPIR-V is going to become more common. glslang also supports older versions of HLSL as far as I'm aware and maybe it might get new functionality if added though it currently lags behind DXC.

In terms of ZVulkan, it's perfectly functional for now, I just noticed the project is macOS 10.13(first OS to use Metal 2) based and there's a few macOS 10.15 features in the new ZVulkan glslang version. It means either the current version of ZVulkan an older library would have to remain in future gzdoom versions or else we'll just have to bump support to 10.15 minimum. It's not the only library complaining either, there's things like dark mode in the main cocoa implementation that also require 10.15. Maybe a last version on 10.13 for 4.15 might be a good idea? I'll speak to the developers when I pull request the cocoa window code.

n.b According to Gemini after a quick search, it should be fairly simple to detect using getenv()

#include <iostream>
#include <cstdlib>
#include <string>

// Include necessary headers for the libraries (e.g., for glib/gsettings)
// #include <glib.h>
// #include <gio/gio.h>

std::string getSystemFontDynamically() {
    const char* desktop_env = std::getenv("XDG_CURRENT_DESKTOP");
    if (desktop_env != nullptr) {
        std::string env_str = desktop_env;
        if (env_str.find("GNOME") != std::string::npos) {
            // Use GSettings C API to get the font name
            // Example: GSettings *settings = g_settings_new("org.gnome.desktop.interface");
            // GChar* font_name = g_settings_get_string(settings, "font-name");
            // return std::string(font_name);
            return "GNOME Font Logic Needed";
        } else if (env_str.find("KDE") != std::string::npos || env_str.find("Plasma") != std::string::npos) {
            // Use KConfig C++ API to get the font name
            // return "KDE Font Logic Needed";
        } else if (env_str.find("XFCE") != std::string::npos) {
            // Use Xfconf C API
            // return "XFCE Font Logic Needed";
        }
    }

    // Fallback using Fontconfig C API (universal)
    // You would link against -lfontconfig
    /*
    FcPattern* pattern = FcPatternCreate();
    // ... use FcFontMatch to find default font path
    FcPatternDestroy(pattern);
    */
    return "Fontconfig Default Fallback";
}

// In a real application, you would link the appropriate libraries 
// and handle memory management (e.g., g_free for glib).