Open gingerbeardman opened 4 years ago
This is also necessary for the HTML5 platform, as you can't access the native file system of the device with the FileDialog when running a game/app on browser.
@OverloadedOrama I've added that to the above proposal, thanks!
FTR, in Orama-Interactive/Pixelorama they work around it with Pukkah/HTML5-File-Exchange-for-Godot.
For those interested in implementing this it seems like this is a good resource for implementing it on windows: https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ifiledialog
Although I see no reason why https://github.com/mlabbe/nativefiledialog cannot be pulled into third party
portable-file-dialogs could be used to implement native file dialogs and desktop notifications.
portable-file-dialogs could be used to implement native file dialogs and desktop notifications.
This looks great! Just note that it doesn't support web yet: From the readme:
Experimental support for Emscripten is on its way
I think using it and helping them with a web implementation is the right way to go
This may be solved by this PR, although I still think native file dialogs would be a great addition.
This may be solved by this PR, although I still think native file dialogs would be a great addition.
I have replaced it with the full native dialog implementation - godotengine/godot#47499
portable-file-dialogs could be used to implement native file dialogs and desktop notifications.
It won't work with the sandboxed macOS apps, since it is relaying on customs scripts, which the sandboxed app won't be able to execute, and even if it was, it won't share permissions with the main app and preserve it across the sessions.
Other than mine, I can imagine a lot of GUI projects currently stuck because of this.
If you are making a mobile app, in most cases you require the user to load a file, e.g. to restore a backup of user's data; but even in games, allowing the user to load a "skin.png" file or stuff like that is pretty common.
And right now it's simply impossible because FileDialog
is ultra-bugged, and even more bugged in mobile.
Throwing my 2 cents in that I'd like to see this core as well. Currently running into this issue for a UI I developed that involves uploading a file to be scanned by a backend. Works great on windows export, unfortunately not possible on the HTML5 build.
I took a stab at this and it looks like portable-file-dialogs
relies pretty exclusively on the C++ stdlib. I remember reading a while back that Godot stays away from std--is that still the case?
Edit: A quick find shows me a lot of internal stuff relies on std::
so I'm going to assume it's alright I suppose.
Edit 2: After a couple hours of re-learning C++ I've got a working prototype going. This is my first-ish time working with the Godot codebase, so I'd appreciate a look.
var dialog = NativeFileDialog.new()
print(dialog.is_supported()) # whether native dialogs are supported on this system
dialog.set_window_title("Pick a file, any file")
dialog.set_file_mode(NativeFileDialog.NATIVE_FILE_MODE_OPEN_FILE)
dialog.popup()
# has_result() returns false as long as the window's still up
await dialog.has_result
var result = dialog.get_result() # when there is no result, `get_result()` blocks until the window leaves
print(result) # file path
Some notes:
popup()
a dialog more than once. I got tired of trying to figure out why. Edit: as of this morning I done went and fixed itFileDialog
FileDialog
class, but there are definitely some fundamental differences that keep it from being 1:1. Edit: as of this morning I'm quite pleased with the feature parity between NativeFileDialog
and FileDialog
, and I think the current design works as an abstraction layerI took a stab at this and it looks like portable-file-dialogs relies pretty exclusively on the C++ stdlib. I remember reading a while back that Godot stays away from std--is that still the case?
Using stdlib is OK in third-party libraries. In fact, it's sometimes used in core Godot as well (e.g. for threading primitives). Other than that, we avoid using stdlib containers within Godot core.
The only restriction is that third-party libraries need to be buildable with C++ exceptions disabled, as some platforms don't support them well (or at all).
Awesome. I'll double check for no exceptions when I'm back at dev.
I did have a couple of wrapping-up questions if you've got the time--
_process
and emit a window_dismissed
(or similar) signal when it detects the change. Still, that feels a little inelegant, and if I'm missing a better way (maybe a C++-side await
equivalent or a structure for it?) that'd be good to get info on.@spindlebink Hi! I have been recently working on an addon for this same feature. It's almost finished, just missing Windows and Mac executables and documentation, if you want to check it out https://github.com/98teg/NativeDialogs
Is there a guide somewhere for editor-specific stuff in a class? I still need to add an icon, editor description, tooltips, etc. and I'd like to get that done while still developing the initial version, since it's often less likely to be completed later on.
See Editor icons and Editor style guide in the documentation.
Adding tooltips to properties is done by exposing them to the scripting API, then updating the class reference.
Do you have a suggestion for a way to add an emitted signal to this class? The library only provides checking for whether the window has closed, so my first instinct would be just to add a check during
_process
and emit awindow_dismissed
(or similar) signal when it detects the change. Still, that feels a little inelegant, and if I'm missing a better way (maybe a C++-side await equivalent or a structure for it?) that'd be good to get info on.
I'm not sure if it can be done any other way than with _process
, as C++ does not have a built-in equivalent of await
or yield
.
I'm not sure if it can be done any other way than with
_process
, as C++ does not have a built-in equivalent ofawait
oryield
.
That's the way I handle it and it works fine.
I have been recently working on an addon for this same feature. It's almost finished, just missing Windows and Mac executables and documentation, if you want to check it out https://github.com/98teg/NativeDialogs
Looks awesome, I like that you've bound to the other dialog types as well. Probably won't be implementing anything but files for an initial version but possibly we could pull in some stuff from yours for an eventual update. I do think having this stuff in core is a great idea although I wish I'd found your library before doing stuff from scratch.
I'm not sure if it can be done any other way than with
_process
That's the way I handle it and it works fine.
Sweet, that's easily doable then. I'll have a new version ready by this evening.
Tangental but native color pickers are useful too as they lets you color pick anything on screen, rather than just the things Godot draws.
The plugin I mentioned earlier is now finished and available at the asset library. I hope you find it useful while this functionality gets added to Godot.
if you use xdg-desktop-portal you're gonna break netbsd and openbsd support (well, it's possible for them to port portal, but without flatpak it doesn't make sense)
when it comes to linux and bsd it's complicated to tell what is native, if you use kde, lxqt, deepin or lumina then you surely get qt file picker, in all other cases you unfortunately (if you use raw window manager but you like qt more than gtk) get gtk file picker
considering people use raw window managers to save resources, tcl/tk is a good option, because it's extremely easy to implement support for it and it uses native file picker on windows and macos, but implements its own on linux and bsd, you don't even need to use it as a C library (although it's designed to be embedded that way) because you can just use it from command line (assuming it is installed in PATH) echo 'wm withdraw .; puts [tk_getOpenFile]; exit' | wish
(other methods are tk_getSaveFile
and tk_chooseDirectory
) and it returns either empty string if user pressed cancel or path to file/directory if user pressed open/save/ok
Is this still being considered? I'm thinking of building an application with Godot and I would really like the native file dialog.
Is this still being considered? I'm thinking of building an application with Godot and I would really like the native file dialog.
There's a pull request implementing this feature for macOS: https://github.com/godotengine/godot/pull/47499
For other platforms, https://github.com/godotengine/godot/pull/60603 can be used but it doesn't handle sandbox mode on macOS.
Afaik, native file selection dialog support is implemented for Windows, Linux and macOS. What's status on Android, Web and iOS?
Afaik, native file selection dialog support is implemented for Windows, Linux and macOS.
It is implemented on Windows, Linux and macOS, but only for projects and for file system
access, Godot Editor currently does no use them. Some of the editor file dialogs have custom controls added. Native dialogs can display extra options on all supported platforms, and it should be sufficient for the editor needs (I'm working on adding support for it).
What's status on Android, Web and iOS?
Not implemented on iOS, Android, native file selectors can be implemented, and probably will be much more convenient for users due to limited file system access. Web does not have any access to the real file system.
Web does not have any access to the real file system.
It's already possible to call custom JavaScript code that brings up native file dialogs that have access to the device's file system, see https://github.com/Pukkah/HTML5-File-Exchange-for-Godot. Would something like this not be possible to be implemented in Godot as built-in methods?
Native file dialogs are now supported for all desktop platforms via FileDialog's use_native_dialog
property.
Hi everyone, I've created a draft for the Android system file picker https://github.com/godotengine/godot/pull/98350. It would be great if you could test it and let me know if you encounter any issues or errors.
EDIT: Now it is also supported for Android 🎉
Describe the project you are working on:
Describe the problem or limitation you are having in your project:
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
regarding the above issues, allowing use of system file picker:
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
similar to these existing libraries, but cross platform and in core:
If this enhancement will not be used often, can it be worked around with a few lines of script?:
Sadly not, core provides no mechanism for accessing native file pickers.
See https://github.com/godotengine/godot/issues/13177 for more history
The ongoing effort of creating a better file picker https://github.com/godotengine/godot/pull/36053 will still not help this issue.
Is there a reason why this should be core and not an add-on in the asset library?: