Couple Suggestions

[mystadio]

Hey, I've been messing a lot with LÖVE and I have a couple suggestions:

Add a file browser: it would popup a file browser window that allow the user to select a file. This function should have at least a filter parameter ( "*.map" ) and another one for the file access mode (read or save). This parameter is for security: it would allow this file to be opened only for either reading OR saving purpose. This function has to return the path and the filename or nil if the user cancels. It would also add the selected filename to an "approved file list". We would then be able to include/require/open the file.

Add binary operators: at least 2 functions... something like "love.bit.and(value1, value2)" and "love.bit.or(value1, value2)". These functions would have their registered C functions that should be like this:

Code: Select all

// love.bit.and
static int love_bit_and(lua_State *L)
{
	int n = lua_gettop(L);

	if(n < 1 || !lua_isnumber(L, 1))
		luaL_typerror(L, 1, "number");

	if(n < 2 || !lua_isnumber(L, 2))
		luaL_typerror(L, 2, "number");

	lua_pushnumber(L, int(lua_tointeger(L, 1)) & int(lua_tointeger(L, 2))); // for the OR function, replace & by |
	return 1;
}

One last suggestion is to add backward compatibility: in the conf.lua file we specify a LÖVE version. When registering C functions, you should register only the functions that were available to that version (including now deprecated ones) and also register them in a way that the parameters and return values are what they were for that version.

I think my two first suggestions are the ones that are more important, the last one would just be a cool feature to allow us to play older games.

Thanks for reading and grëät work guys!
Josh

[rude]

Hey.

• File browser: That's a good idea. I hadn't though of that. It would, however, require some sort of GUI-library, and I want to avoid such dependencies at all cost.
• Binary operators: LuaBit isn't good enough for you? I'm not going to prioritize this, buf if you want to create love.bit in C, I'll be happy to include it.
• Backward compatibility: That sounds very cool in theory, but we have nowhere near that much control of exposed functions (most of the wrapper code is SWIG'd).

^_^

[mystadio]

File browser: There's no need to use the "official" file browser provided by the OS. It could be done inside the game.
Here is what an idea of a way to do it: when calling the function love.filesystem.browse (just an example) the LÖVE engine would either hide or display a transparent gray overlay to make a disabled effect and draw a simple file browser over the fixed background image. That file browser should only use "ls"/"dir"/ etc. command to reach the desired file.
Also, the programmer could personalize the file browser box by setting its border color, background color/image, etc.

Binary operators: I took a look at LuaBit's code and it's really well done for a lua script. But the main issue is that it is written in lua... Bit manipulation is not easily done using only lua (they have to store each bits in a table and than apply the operator over 2 tables). It is slower than calling one C function that doesn't a really simple and native operation.

[mystadio]

You should also add a link on the top left image to go back to the homepage while in the doc. I hate having to scroll down to the bottom of the page to click the small "Visit homepage" link.

[cag]

Well, here's my thoughts on the file browser: it's a very high-level operation, so introducing it in the API would be a bit like giving the API a trojan horse (in the classical Trojan War sense).
As of right now, LOVE is designed as a game engine that gives you the lower-level tools to make your own higher-level tools. Notice the excellent LOVE console was coded entirely in lua/love, and it works pretty awesomely.
Making a bona-fide file browser would no doubt cause a rather large inconsistency in the API, given every other operation is well defined, relatively small, and in it's own little module. That produces the possibility that people would want more such module-mixing high-level functions in the API, so poor LOVE devs would have to keep up with developing those things instead of spending time slowly improving LOVE.

The binary thing is ok to me, though personally, I'd probably never end up using any of these functions anyways. Because I'm lazy, and LOVE devs are, um...
Well, apparently they are crazy. But I don't think they've found a pressing need to use binary operators yet. Perhaps an argument might prove me wrong?

Anyways, I don't want to entirely discount the file operations notion. Perhaps LOVE devs should consider adding some sort of command line/config option to allow the use of lua's native file operations? Because that way, tool devs can code a LOVE file browser, and game devs could just choose not to use the extended file functionality in their game. Or thoughts... actually this may have been suggested before by somebody else.

[surtic]

I quite like the simplicity of clicking on a .love attachment and running it without wondering which files are going to be overwritten this time (or read and sent over the net using LuaSocket...)

Of course, we have many programs that write to files and we don't expect them to ask "are you sure?" before every file operation. It's just not something I'd expect from a game - having it sandboxed is actually a good thing.

I can imagine a game distribution system (as was discussed before in a different thread), where people can download (casual) games and just have a go. As hobby games they're not going to go through any strict examination, and it would be nice to know that the games can't actually harm the computer.

[mystadio]

The goal of the file browser is to let the user choose which files the program can use. The program will only have access to files selected by the user (if any) and won't be able to overwrite a file which has been selected in an "open file...".

Here is an example:

Code: Select all

local filepath, filename = love.filesystem.filebrowser("*.map", love.fileaccess_read);
if not filepath then
  -- user canceled
else
  -- open the file, read it and load the map.
end

The different access mode would be:

• love.fileaccess_read: the programmer can only open the file for reading purpose.
• love.fileaccess_save: the programmer can only open the file for writing purpose.
• love.fileaccess_all: the programmer can open the file for reading and writing purpose.

The access mode requested for the file would be displayed in the file browser title to let the user know the program's intention. ("Open file...", "Save as...", etc)

For even more security, the love.filesystem.filebrowser function would return only a fileId (to hide the filepath) and the programmer would have to open a file using the fileId as a parameter instead of the filename .. filepath.

[rasjani]

Like few people mentioned allready, i dont see any reason why such feature (filebrowser) should be incorporated into love itself. Infact, for image/pr purposes i'd suggest against such feature. Love should be as "hidden" as much as possible for "serious" people to consider it as a viable development/deployment platform..

However, it would nice if there would be some sort of cooperation that would produce base widgets that could lead to such highlevel functionality to be implemented.. One of the reasons why python/perl have been successfull is the 3rd party libraries and central repositories build them and i dont see why we wouldn't be able to do the same with love/lua ..

[surtic]

I was responding more to cag, really.

There's a problem here: on the one hand a file browser doesn't sounds like a feature consistent with the rest of the API. On the other hand, allowing developers to write such a feature means that there's some way to load/save files (even if has to be enabled in the config file), which is dangerous.

Personally I don't see any way out of it except for writing tools in another environment (maybe with a LÖVE library that provides the interaction side). I don't think love.exe as it is distributed today should become a "dangerous" application just to allow people to write tools. However, it's not up to me, really. I can only share my opinion that so far I haven't been reluctant to open .love files, and I like it that way.

[rude]

Making a bona-fide file browser would no doubt cause a rather large inconsistency in the API, given every other operation is well defined, relatively small, and in it's own little module. That produces the possibility that people would want more such module-mixing high-level functions in the API, so poor LOVE devs would have to keep up with developing those things instead of spending time slowly improving LOVE.

You're pretty much spot on here, cag. It would involve mixing graphics, filesystem and input internally, which should be avoided if possible.

I can only share my opinion that so far I haven't been reluctant to open .love files, and I like it that way.

*Ehehehe*, yeah ... ^.^)'' about that ... the io library is still available. You all knew that, right? We've planned to remove it several times, but Mr. Strange keeps stopping us with his clever arguments and doomsday predictions.