browse for file/directory widget

[Xeverous]

This issue is for tracking any decisions before implementing this widget.

• likely just a button with predefined on_click function
• requires platform-specific code

[djowel]

This is best done using platform code; Probably outside the scope of the library? I'm not sure.

[Xeverous]

Not sure about other systems, but Windows has a set of predefined modal dialogs

https://docs.microsoft.com/en-us/windows/win32/dlgbox/dialog-box-types

You just call an API function and it creates a modal window managed by the OS, the function will return (with user data) when the window is closed.

[djowel]

All platforms have those. It might be good to abstract this in a cross-platform API, but I am not sure where to draw the line which elements should support. How this is triggered is App specific. It can be from a menu, a button, etc.

[Xeverous]

True, I was thinking more about providing such platform-abstracted API so one can easily create a custom widget and do something like w.on_click = os_modal_save_as().

[djowel]

True, I was thinking more about providing such platform-abstracted API so one can easily create a custom widget and do something like w.on_click = os_modal_save_as().

Agreed. Probably worth looking into.

[Xeverous]

I'm in the process of looking how other GUI libraries handle this and designing a common OS-agnostic API.

Windows and macOS interfaces are rather rich - what should I be looking at for unix systems? GTK+ 3 API?

[Xeverous]

I started making a sheet which compares major OS APIs and libraries (Windows, Mac, GTK+ 3, wxWidgets 3, Qt 5). Turns out all of them have very rich set of settings.

Core functionality like path filtering, default file/dir are present in all. For each of other/advanced options, it is present on most targets.

Both Qt and wxWidgets cover almost all and ignore specific ones on platforms on which they are not available. IMO this is a very good design.

The eventual interface in elements can be a free function that takes 1 parameter: options struct. This way:

• for each option elements can provide a very reasonable default value
• we can add more options later without any API breakages
• Elements library users can do what they want with the options struct. file-save-as / file-open and directory-open share a lot of common settings and it would be good to store them in a common member struct. This way library users can easily implement consistent behavior.

[djowel]

Windows and macOS interfaces are rather rich - what should I be looking at for unix systems? GTK+ 3 API?

Yes GTK3 on Linux

[djowel]

The eventual interface in elements can be a free function that takes 1 parameter: options struct. This way:

• for each option elements can provide a very reasonable default value
• we can add more options later without any API breakages
• Elements library users can do what they want with the options struct. file-save-as / file-open and directory-open share a lot of common settings and it would be good to store them in a common member struct. This way library users can easily implement consistent behavior.

Sounds good to me! I suggest starting basic. It's always easy to add APIs than to remove APIs, especially when the library gets established.

[Xeverous]

This is going to take some time, but I can share my WIP spreadsheet if you want.

[djowel]

This is going to take some time, but I can share my WIP spreadsheet if you want.

Google sheet will be good.

[Xeverous]

Actually, it's easier for me to work on the spreatsheet offline. I already switch too many browser tabs too often when reading various documentation. I can upload it here when I finish.

[Xeverous]

OS API notes.xlsx

These are all of my current notes on all 3 filesystem dialogs:

• save file
• open file
• open directory

[djowel]

Wow, that's a lot! Nice work collecting that. So basically, as always: Start with a minimal subset that is available on all platforms.

(BTW. I wonder how you are able to test on MacOS, do you have a Mac you can work on?)

[Xeverous]

I'm not able to test it on mac. I don't even have Obj-C skills. All from the sheet is from API documentation. I will left Mac implementation for you.