tseli0s / nvdialog Goto Github PK

Hi,
I tried to compile and use this library on MacOS (12.6 Monterey), but the problem is that when I show a dialog if I click on OK button it hangs.
The issue is exactly same as this one:

https://developer.apple.com/forums/thread/19540

Most sandboxed environments such as Flatpak have specific restrictions that make a large part of NvDialog unusable (File dialogs, notifications, ...). The hardest part is that for each backend, we will have to manually implement it's own way of doing these.

The good part is that Windows has great backwards compatibility meaning UWP applications should behave the same under NvDialog as if they weren't sandboxed, except for hiding / denying access to some parts of the disk.

Flatpak on the other side requires DBus in order to ask for any sort of permission. If anybody is experienced enough, maybe they can implement it (And save some time) but most likely, we are gonna have to use Gtk's existing solutions for the file dialogs and let notification access up to the end user to determine.

This is a tracking issue, meaning that it tracks something that should be fixed or added in the future.

During some internal rewrites for v0.8, macOS-specific code for NvDialog no longer compiled, leading to some calls being hardcoded to return NULL. There will be a patch release for v0.8 addressing exactly this.

Just a question. The docs of https://learn.microsoft.com/en-us/windows/win32/api/commdlg/nf-commdlg-getopenfilenamea say that they are superseded by IFileOpenDialog, So why not use IFileOpenDialog ?

NvDialog opens libnotify (For notification support on Linux) using the dlopen call (Basically linking libnotify manually at runtime, here you can learn more). This helped decrease dependencies as one who did not desire notification support could just disable it. However, this means we must manually find the library.

For now, NvDialog hardcodes the expected path at /usr/lib/libnotify.so. However:

• Debian, Ubuntu and derivatives use a different filesystem look than Arch and Void (Which is where this library used to be developed).
• Sometimes the .so extension may be followed by the library version (NvDialog does this as well), however the hardcoded path won't be able to detect this.

So, here is my own solution:

• Detect distribution at run time, and set path accordingly,
• Use the set path of libnotify to load the library when needed,
• And have a fallback path ready, in case the original one isn't found

(The issue is mostly fixed, we only have to make the backends use the new path)

MacOS X is the second most popular OS in the desktop market and not supporting it is sort of ironic. The two backends (Currently working to some degree) basically correspond to two platforms:

• Gtk3 on Linux, which works seamlessly.
• the Win32 API on Windows (+Wine), which also works fine although some functions take longer to be implemented.

For MacOS, we have two options:

• Use Gtk there too, since Gtk is cross-platform or,
• Use the native MacOS APIs, which I can't really do anything about since I don't have any Apple products and don't plan on buying any, hence someone will be in charge of doing this.

I am leaning towards the first because MacOS and Linux are pretty similar (both Unix-like) so it will save alot of time. However I've heard lots of horror stories when building Gtk so I'm still sceptical.

When testing with winit and the Rust bindings to this library, it appears that Gtk causes a segmentation fault to the process by dereferencing an invalid pointer as a mutex. This unfortunately makes NvDialog impossible to use with winit, and largely defeats the purpose of a cross-platform library.

Currently this does not appear with GLFW on Linux, and other platforms do not have the same problem. Which easily pinpoints the issue to Gtk's windowing internals.

For the users of NvDialog, you are advised to temporarily stop using NvDialog until the issue is resolved or use another windowing library.