String marshalling fix

[ds5678]

Hello again. I solved the issue I reported in #2. It was caused by native not being Utf8 on all platforms. I bumped CppSharp to the latest version and ran it on the header for Native File Dialog Extended v1.1.1.

[Speykious]

Awesome! Gonna check that everything still works on my machine and stuff

[Speykious]

I'd gladly accept this change, especially if it means making sure we're using utf-8.
But unfortunately, that change is not gonna work on Linux (and fwiw, on Mac too). :(
On non-Windows platforms, since the native charset is already utf-8, in nativefiledialog-extended, they're defined as a C macro:
https://github.com/Speykious/nativefiledialog-extended/blob/ab1e78eb5462f153d247bad309760d0bd67a6d57/src/include/nfd.h#L266-L273

I think I (or you?)'ll need to slightly modify the CppSharpGenerator so that it changes the names of the functions on non-Windows platforms.

[ds5678]

If you know how to fix it, go right ahead. You should have push access to my branch.

Otherwise, I'll take a look tomorrow.

[Speykious]

So far I've tried a somewhat naive approach of adding function name replacements (N to U8) in the PostProcess method when not on Windows, and I think it seemed to work up until it was time to find the nfdu8filteritem_t type. I think CppSharp can't find it yet again because it's a #define, but I can't find a function to rename that type...

[ds5678]

I think the best solution might be to ask the native library author to make the API universal. A few small tweaks upstream and generating interop bindings becomes easier for all frameworks.

[ds5678]

If we pr that change upstream, the utf8 methods will work out of the box on all 3 platforms.

However, the native methods will have cross platform differences. Currently, the CppSharp output code aligns with Windows wide characters. I propose we add SupportedOSPlatform attributes to the native methods. That would warn developers that they should only use the native methods on Windows.

[ds5678]

btzy/nativefiledialog-extended#118

[ds5678]

https://github.com/AssetRipper/nativefiledialog-extended/actions/runs/7152679491

[Speykious]

Well that was fast :v

[ds5678]

I also want to pr doxygen support to the native library because that will let CppSharp pull the documentation for our library.

[ds5678]

I also asked about injecting attributes.

mono/CppSharp#1804

[ds5678]

I also asked about injecting attributes.

mono/CppSharp#1804

I was able to inject the attributes!

    public void Postprocess(Driver driver, ASTContext ctx)
    {
        foreach (var function in ctx.TranslationUnits.SelectMany(t => t.Functions).Where(f => f.Name.EndsWith('N')))
        {
            AddWindowsOnlyAttribute(function);
        }
        AddWindowsOnlyAttribute(ctx.FindClass("NfdnfilteritemT").First());
    }

    private static void AddWindowsOnlyAttribute(Declaration declaration)
    {
        declaration.Attributes.Add(new Attribute() { Type = typeof(SupportedOSPlatformAttribute), Value = "\"windows\"" });
    }

[ds5678]

A few updates:

• My upstream changes were merged!
• I set up automated building. https://github.com/AssetRipper/nativefiledialog-extended-builds/actions

[Speykious]

Oh my god... I didn't have any Readme file all this time?? This is bad 💀

[Speykious]

I'll update NativeFileDialogs.Net.Runtime now

[ds5678]

Much appreciated

[Speykious]

If you know how to fix it, go right ahead. You should have push access to my branch.

Otherwise, I'll take a look tomorrow.

Well... apparently I don't! D:

❯ git push AssetRipper HEAD:string-marshalling-fix
ERROR: Permission to AssetRipper/NativeFileDialogs.NET.git denied to Speykious.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

[ds5678]

What were you trying to change? Just bumping the NuGet version?

[Speykious]

Yes, on all packages for NativeFileDialogs.Net.Runtime, and also change the submodule since we don't need my fork anymore.

[ds5678]

I don't think you can push to my branch, probably because I made this from an organization repository.

[Speykious]

I see. Is there anything you can do in the organization itself then?

[ds5678]

I added permissions for you to push to that repository, so you should be good now.

[Speykious]

Thanks, it worked :D

[Speykious]

The examples work on my end with the new versions! I'll do one more test before merging.

[ds5678]

I noticed that you were referencing the Autogen NuGet package. It's only necessary to reference the Runtime NuGet package due to how native libraries are used.

[Speykious]

Oh damn, it has actually never worked on Mac. I'm getting a DllNotFoundException. It can't find the libnfd.dylib in the right place no matter what name I give the runtimes/osx-... directory. I guess that's a separate issue I'll have to pull up.

[Speykious]

I noticed that you were referencing the Autogen NuGet package. It's only necessary to reference the Runtime NuGet package due to how native libraries are used.

What do you mean? As in I should turn AutoGen into a project reference instead?

[ds5678]

613358e

[ds5678]

Whenever you compile, all the NuGet references will be correct in the generated packages.

[Speykious]

Ah right. Yeah that's what you meant. That's fine