love2d
Add an open-file popup dialog function
Original report by Eliter Scripts (Bitbucket: EliterScripts, GitHub: EliterScripts).
can there be something like love.graphics.UserSearch(Arg1,Arg2) can everyone who is looking at this go into Google Chrome (a web browser, look it up), type in "Chrome://settings" in the address bar, scroll down all the way to "Show advanced settings..." and click that. Then to the left of the "Download location:" there is a box, click it. See that window that popped up? can you guys put that into love2d, so like a User Avatar picture would be EASY for the user to locate. It would be so awesome. Now, for love.graphics.UserSearch(), the first Argument, being what directory to be looking first (Like, in chrome, it's probably at, by default, looking at "C:\USERNAME\Downloads"), the Second argument could be nil, OR a string. The second argument, if it is nil, then ALL the directories and files will be displayed. When the second argument is a string, it will look at ALL the directories, but will only view the file extension that is the same as the string that is Arg2.
That make sense?
Original comment by Sasha Szpakowski (Bitbucket: slime73, GitHub: slime73).
LÖVE 0.10.0 will have support for dropping files and folders onto the game's window. Will that be enough for you, or would an open-file-dialog function still be useful?
(Also, for reference, is there a standardized API for this in Linux? On Windows there's GetOpenFileName and on OS X there's NSOpenPanel.)
Original comment by Eliter Scripts (Bitbucket: EliterScripts, GitHub: EliterScripts).
Im not sure what "an openj-file-dialog function" is. Sorry. Also, is there a possibility that there could be ability to move in and out of windows. Like, after you download something on Chrome, you can drag the file from the bottom bar, onto your desktop, or drag a file from somewhere else, and drop it into a website. I think you could play around with some ideas from love.window.showMessageBox() stuff.
Original comment by Sasha Szpakowski (Bitbucket: slime73, GitHub: slime73).
Im not sure what "an openj-file-dialog function" is. Sorry.
It's this (the thing that Chrome displays in your description): http://blogs.msdn.com/blogfiles/wpfsdk/WindowsLiveWriter/OpenFileDialogsample_CAB7/OpenFileDialog_Dev10_2_thumb_1.jpg
Original comment by Eliter Scripts (Bitbucket: EliterScripts, GitHub: EliterScripts).
Yeah, I think an "open-file-dialog function" would be pretty cool. But, if drag-and-drop is all you can do, it would totally work. It's just that I'm creating a program, that requires a directory to be chosen, and files being read in it, but I need the user to decide every time it runs, where the directory is.
Original comment by Robert M. (Bitbucket: rmcode, GitHub: rmcode).
@slime73 I think the addition of an "open-file dialog" would especially be handy for tools like level editors, paint applications and other utilities made with LÖVE.
Then again "drag & drop" might be more convenient anyway ...
Original comment by Eliter Scripts (Bitbucket: EliterScripts, GitHub: EliterScripts).
How much is the bribe? I really need this API, so I can continue the program. This if fatal to the program!
Original comment by Robin Wellner (Bitbucket: gvx, GitHub: gvx).
New LÖVE versions tend to take a long time, so I wouldn't wait on it, @EliterScripts
Original comment by Sasha Szpakowski (Bitbucket: slime73, GitHub: slime73).
Considering file drop events have been added to LÖVE 0.10.0 and this feature wouldn't have complete cross-platform support, I'm marking this as wontfix for now.
Original comment by yomgui oim (Bitbucket: chafporte, ).
just add tinyfiledialogs from sourceforge to your source and mark the issue as fixed.
Original comment by Kyle McLamb (Bitbucket: Alloyed, GitHub: Alloyed).
For anybody who comes across this issue, I made a set of bindings to get Windows/MacOS/Linux file pickers, that I've been using just fine with love:
https://github.com/Alloyed/nativefiledialog/tree/master/lua
Note: it's a blocking API, so I suggest spawning a thread to handle dialog boxes, and since the underlying library doesn't ask for a parent window it doesn't do the thing native dialogs do where they redirect focus from their parent to them, but it works okay4me
Original comment by Seppi (Bitbucket: josefnpat, GitHub: josefnpat).
I've done some research, and as @chafporte mentioned, as old as tinyfiledialogs looks, it most certainly looks accredited.
https://sourceforge.net/projects/tinyfiledialogs/
There have been many instances where a file picker would have been fantastic; drag and drop into the app doesn't really cut it from a UX standpoint.
Can we mark this ticket as open again?
Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).
I'll look into it again at some point, but don't get your hopes up (yet).
Original comment by Daniel Power (Bitbucket: danielpower, GitHub: danielpower).
If you're willing to include imgui, I've written a file picker dialog that should work for you.
I wrote it for my animation editor called Motion. But I made sure when I wrote the file picker that it would be portable for use in future projects.
You can find it here: https://gitlab.com/DanielPower/motion/tree/master The filedialog itself is in widgets/imguiFile.lua For an example of how to use it look at interface.lua since that's where all the calls are.
Edit: A previous version had support for thumbnail previews, but it's been temporarily removed while I improve the layout.
Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).
Of course that does require luafilesystem. (It looks nice, btw.)
Original comment by Daniel Power (Bitbucket: danielpower, GitHub: danielpower).
Once 0.11 is released, I'm going to begin packaging luafilesystem and imgui with the file dialog, and dropping them into the save directory, since (according to holo on irc) love will 0.11 will use the save directory as cpath.
That way no dependencies will need to be installed manually.
Original comment by Pablo Mayobre (Bitbucket: PabloMayobre, GitHub: PabloMayobre).
I support @Alloyed proposal of using nativefiledialogs, the dependency is really small and pretty much crossplatform (works in Windows, Linux and MacOSX)
For me it just worked out of the box, it was really easy to build it too
Original comment by Mi 28 (Bitbucket: rcoaxil, ).
Given that you cannot mount a point you didn't select in current session, its usability is limited, at best. To leverage the filesystem you'll have to bite into physfs via FFI, and at that point you might as well bring your own binary library for native dialogs.
Original comment by itraykov (Bitbucket: itraykov, GitHub: itraykov).
To be honest, I don't think this is a good idea. Even if you were to write an editor in Love2D, the native file dialog would look out of place with your editor. Would not be very convenient in full-screen mode either. So yea, it's probably best to use something like Daniel Power's solution.
Original comment by Ross Grams (Bitbucket: rossgrams, ).
Yes, built-in nativefiledialogs support (or similar) would be really, really nice. You can't beat the native dialogs for UX. I would use it constantly for various editors, tools, and loading user-made content (custom maps, mods, images, etc.).
I have to disagree with itraykov. Personally, on the occasions when I would actually care about looks (i.e. not for an editor) I think a native dialog would look much more professional than any homebrew solution.
Dropping files and folders onto the window is nice, but for me it's not as good as an Open/Save As dialog, and definitely not the first method that comes to mind.
Original comment by Nicolás Abram Luján (Bitbucket: [nicolas abram lujan](https://bitbucket.org/nicolas abram lujan), ).
I also think this would make a very nice feature. A lot of people like having os native popup windows (Like qt does afaik, compared to gtk which i think does the same ui for all systems). nativefiledialogs looks like a small, reliable dependency to add which would allow it. I think just adding it to the binary would be enough with the ffi if no one wants to actually add the bindings.
Original comment by Gabe Stilez (Bitbucket: z0r8, ).
If people would be more sated with an "in-game" solution, i do believe that there's only three things stopping that;
-
a way to access files outside of löve's "sandbox",
-
a library over such a thing that could be themed to anything the user desires,
-
if SDL supports this, it would be real nice if the file/directory-dropped callbacks would also contain in window-space the coordinates where you dropped the file/directory.
I've already wrote a semi-solution to the first issue (using only PhysFS, which already comes with löve; access is fine, but writing to arbitrary places is still problematic, and of course the two mobile backends might not work at all (hence why i'm not proposing this to be included in löve proper, for one); the rest was tested, i believe, on discord. The second issue is really not that big of a deal once the first works as much as it can. And if those two are done, the third would be just an extra nicety on top. (Example case would be, your game behaves differently where you drop a certain file let's say, in the window.)
(Also, this is just a bit off-topic i think, but similar alternative solutions have been proposed above, so i didn't feel it to be too much of an issue.)
This is something that I was thinking about for a long time, and just now found an issue for it.
Although love.filedropped can be nice in some cases, I still consider it "secondary" relative to the usual OS's file dialog.
Sometimes a file dialog can be more convenient, for example to ask the user where to save a file to.
Are native file dialogs planned in any way for future versions of löve?
This has been brought recently too and the idea is to use Zenity or KDialog in Linux.
The next question is how would the API look like? On what module it should belong? Should it be in love.window because it deals with window, love.system because it's system-specific feature, or love.filesystem as it deal with files?
