[RFC] pickFile function

[raidho36]

That was just a made up example, to show that the implementation must be flexible enough. As I said, it would be quite handy, but as you mentioned, there probably isn't so much use to it in an actual game. From my experience with video games, I can name you the single most wide use of filesystem browser thing: to load an save your progress. Some marginal amount of games would also let you browse for maps and alike, such as StarCraft or OpenTTD.

[kaedroho]

Think of it: you were playing a game, then decided to load a save, and when you press "load" menu item some foreign window with system skin on it that looks completely alien pops up prompting you to browse your filesystem for save files, how would you feel?

Normally, you would use the regular methods privided by LOVE to read/write save game files (as they can be stored in the save game directory)

This pickObject function is really for importing/exporting data from a LOVE application. And usually, you don't do that stuff while in game. A couple of examples would be importing an image to use as an avatar or saving a map file to share with friends

[raidho36]

I would honestly rather implemented all of that within a game, but what you suggest makes perfect sense, too. Just make sure that open file dialog is not the only facility available to pick a file that way, that is there should be functions exposed to make it just as simple to implement this same file picker inside a game. Like scandir ( ) that returns a list of files in currently browsed directory and openfile ( ) that would either (depending on supplied item index) enter subsequent directory or select a file and return it's address to load it inside the game.

[Plu]

If I had to name a most used example, I'd look at something like "upload a custom avatar". That'd be pretty cool.

[vrld]

Like scandir ( ) that returns a list of files in currently browsed directory and openfile ( ) that would either (depending on supplied item index) enter subsequent directory or select a file and return it's address to load it inside the game.

As I understood it, the whole idea is that the game doesn't know about the file and folder names. The game will receive only a file handle, which can be used to read/write the file.

Like bartbes I can see a number of interesting use cases - e.g. custom map editors for in-development games, importing user generated content (which will be saved in the identity-directory), etc.

[raidho36]

I don't see the reason why it should be hidden from the game in any way. It won't help security at all since app can simply use Lua's functions instead of löve2d's and access entire filesystem anyway. This framework doesn't have to be deliberately restrict people from commonly used features and be awkward to use. I understand the thing with only allowing root directory and user directory via love.* functions, it forces games consistency to users who can't just keep their files together right, but actually forbidding users from doing certain things would be too far. Besides, if you implement easy to use filesystem browser, why not implement easy to use filesystem browser API so users can make their own filesystem browsers easily?

[Plu]

One important reason would be transparancy. I don't want to poke around in filesystems, because that means I need to have a basic idea of what kind of hardware and software I'm working on. By making a transparant interface, your program will work on all operating systems, as well as handhelds and other stuff, without having to change code because they have an exotic file system or other limitations.

The less you deal with the operating system, the less likely you are to accidentally tie yourself to one.

[raidho36]

I propose to only return a list of strings of file/directory names and maybe file types, the underlying system handles it all on itself, no user interaction involved. So for every location it's currently in, it can either list you what it's contents, as rows (be it some directory or root folder in linux or "my computer" with drives list on Windows) or accept an index of that row to go into, and if it was a file it will return a handle, and if it wasn directory it will return nil and continue to browse folders. No OS-dependent things exposed to the programmer, they doesn't even have to bother over filesystem type or naming restrictions or anything at all, since the whole job is done by the löve2d.

[vrld]

You can already do this, but it's a bit hacky: Filesystem Hack: Set Identity to Whatever You Want. You could build a library on top of that if you wanted, but be aware that you will run in trouble with varying codepages and UTF-8 filesystems.
There is also LoveFS which provides more than what you asked for.

Still, if you only want to provide a way to let a user select files for you to read or write, a hypothetical love.filesystem.pickFile() is lövelier than writing your own filesystem browser. Especially in early phases of the development.

[slime]

Just a quick note - love.filesystem.setIdentity currently has a bug where you can still read from (but not write to) previous identity directories, even after changing it to something else. This is fixed in 0.9.0.