btzy / nativefiledialog-extended

Cross platform (Windows, Mac, Linux) native file dialog library with C and C++ bindings, based on mlabbe/nativefiledialog.
zlib License
698 stars 95 forks source link

Don't use nullptr in fileOpenDialog->Show #126

Closed rcases closed 5 months ago

rcases commented 10 months ago

When window owner is nullptr, the main window can still be selected and a second label appears in the taskbar for the dialog, which is annoying.

To avoid this, you can put the Handle of the main window:

result = fileOpenDialog->Show(find_main_window(GetCurrentProcessId()));

Being find_main_window, the code found in: find_main_window

btzy commented 10 months ago

Yeah, I think this is an issue on both Windows and Linux. I didn't implement this because all the known solutions to determine the parent window are guesswork if NFD isn't given a handle to the main window (e.g. the find_main_window solution you've linked), but yet it would be quite simple for the caller to get the correct window handle and tell NFD about it (assuming the proper API is added to NFD).

The main concern with having the window handle passed explicitly is that it is platform-specific, which means that we need separate platform-specific APIs on each platform NFD supports. But even though it's a bit difficult to use, I think this is the more proper solution and should be preferred to the guesswork you're proposing. Since most users of NFD use a windowing library like SDL2 or GLFW, we could potentially add a way to accept a SDL2 or GLFW window handle (in a separate header, so the NFD library itself doesn't need to depend on those things) and get the platform-specific native handle from it.

rcases commented 10 months ago

Yes, I understand that passing the handle to the window would break compatibility. That is why I have made this proposal that in the worst case (the window handle is not found and find_main_window returns nullptr), it would be the current situation.

btzy commented 10 months ago

Sorry, I think I wasn't very clear.

I don't think the logic of find_main_window should be part of NFD, since it is guesswork, and for multi-window applications it might bring the wrong window to the top. Instead, I think NFD ought to have a new interface that will allow the user to pass in a native window handle, and the user should implement their own find_main_window hack if they want to do so (or better, figure out the correct window handle through a more proper way and pass that to NFD).

This should be implementable after #92 is implemented.