Added Native File Browser for Graph Editor

[dgovil]

This PR adds support for using a platform native file browser on macOS to the MaterialXGraphEditor.

It introduces a new class that matches the Imgui File Dialog API, though limited to just the calls used by the GraphEditor.
Being able to use the native browser allows for quicker navigation to locations the user may have saved, and allows handling of some cases like cloud synced files.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: dgovil / name: Dhruv Govil (95a0e84)

[dgovil]

I went through the CLA registration process and got a confirmation. Not sure if there's a lag time between that and the test updating here

Edit: I think it's because I submitted the commit from my corporate email. Which I've also added to my account, and signed a secondary CLA for, but it looks to not like that. Submitted a JIRA ticket here: https://jira.linuxfoundation.org/plugins/servlet/desk/portal/4/SUPPORT-16422

In the meantime, I've updated the PR with my personal email to unblock it

[kwokcb]

Would be great to get rid of the built in browser on desktop. I "think" it would still be useful as a runtime option however as believe that all UI drawn using ImGui constructs so maintains consistency with the rest of the UI which can have customizable attributes set, and maybe also is more cross-platform (non-desktop) ?

[jstone-lucasfilm]

In a Slack discussion with @dgovil, he suggested the idea of importing the existing cross-platform file browser from NanoGUI into MaterialXGraphEditor, effectively replacing the dependency of the graph editor on ImGuiFileBrowser. This sounds like a good approach to me, and further in the future we might consider moving the imported file browser code from MaterialXGraphEditor into MaterialXRender, making it available for other example applications to use. This future step would require either raising the minimum supported platform for MaterialXRender to C++17, or replacing the std::filesystem references in the file browser code with equivalent functions from MaterialXFormat.

[dgovil]

@jstone-lucasfilm and @kwokcb , I've updated this PR to include the code from the NanoGUI end so in theory it should work on macOS, Windows and Linux. I've only tested this PR on macOS since I don't have a Linux or Windows machine handy.

Would someone else be able to test+modify the PR for those platforms? I think I captured all the includes and CMake configurations that might be needed, but I am not sure of course.

Thanks!

[kwokcb]

Hi @dgovil,
I've checked out Windows. Looks good from my testing.
I don't have access to modify your branch but here's the diff to fix windows builds and clear the file filter properly.
patch.diff.txt

Sorry I don't have Linux. Add in @lfl-eholthouser, to see if she has it, and for review.

[dgovil]

Awesome, thanks @kwokcb . I just applied your patch (just a note, I think your diff was inverted but easy enough to flip)

[kwokcb]

Sorry about that. Must have got args reversed in git diff. :).

[lfl-eholthouser]

Hi @dgovil, I've checked out Windows. Looks good from my testing. I don't have access to modify your branch but here's the diff to fix windows builds and clear the file filter properly. patch.diff.txt

Sorry I don't have Linux. Add in @lfl-eholthouser, to see if she has it, and for review.

Hi @dgovil I tried it out and its working for me on Linux! It looks great! I'm getting a Linux error caused by IM_ifgreater_vector3_genglsl that's affecting the rendering so nothing shows up in the render view. I'm pretty sure this is related to a different change so I'm going to keep investigating that, but for some reason even just adding new folder and the changes to the Graph.h are causing it.

[dgovil]

Thanks for confirming it works!

That error does sound like it's coming from elsewhere unless some kind of preprocessor define caused a conflict?

Though I'd be surprised since the code is largely from nanogui so I'd expect to see the same issue in materialxview

Hopefully it's easy enough to track down

[kwokcb]

The only code that I know which may overlap should be the code for handling focus. i.e. @lfl-eholthouser I assume you added in the code to check focus since the older dialogs being drawn using OpenGL. I don't think they would affect anything but that's all I can think of. Would be good to clean up this code afterwards though.

[jstone-lucasfilm]

Thanks for putting this proposal together, @dgovil, and this looks good to me!