Suggestions for more path retrieving functions for SDL |
Sik
|
In my game you can take screenshots using Shift+F12, and I was
thinking making it store the files in the folder that is normally used to store the user's pictures. Then I realized that such a thing may be useful for programs in general, so I wonder: can we make SDL return the relevant paths to them? Here is the set of functions I propose. They'd be similar to SDL_GetBasePath and SDL_GetPrefPath. ------------------------------------------------------ SDL_GetHomePath() Returns the path to the current user's home directory. If such a thing doesn't exist, it returns whatever directory would be most suitable for that job. If it's impossible to even access those user files in the first place, it returns NULL. SDL_GetPicturesPath() Returns the path to the directory intended to store the user's pictures. If such a thing doesn't exist, it behaves like SDL_GetHomePath. SDL_GetMusicPath() Returns the path to the directory intended to store the user's music. If such a thing doesn't exist, it behaves like SDL_GetHomePath. SDL_GetVideoPath() Returns the path to the directory intended to store the user's videos. If such a thing doesn't exist, it behaves like SDL_GetHomePath. SDL_GetDocumentsPath() Returns the path to the directory intended to store the user's documents. If such a thing doesn't exist, it behaves like SDL_GetHomePath. SDL_GetDownloadsPath() Returns the path to the directory intended to store the files the user downloaded. If such a thing doesn't exist, it behaves like SDL_GetHomePath. ------------------------------------------------------ With Windows you could use SHGetFolderPath for that (yes, I know it's deprecated, but SDL2 still works on Windows XP so may as well keep that around). The home directory would be My Documents I suppose (and yes I know that the last two functions would have to return that as well). With Linux you can get the home directory with getenv("HOME"). As for the other directories, they're in $HOME/.config/user-dirs.dirs (it's a text file), and its format should be self-explanatory once you open the file. If the file is not present it's probably safer to just fallback on the home directory. No idea how it'd work with other OSes but I suppose there are similar APIs. Going for the home directory first is probably a good idea since all other functions will fallback to it in case of failure. Also making the functions return NULL when you can't access the user directories (e.g. because it's a mobile app without enough privileges) is OK I suppose. Comments? _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Suggestions for more path retrieving functions for SDL |
Sik
|
If somebody is interested to know how ~/.config/user-dirs.dirs looks
like, here is mine (note that this is a Spanish setup): # This file is written by xdg-user-dirs-update # If you want to change or add directories, just edit the line you're # interested in. All local changes will be retained on the next run # Format is XDG_xxx_DIR="$HOME/yyy", where yyy is a shell-escaped # homedir-relative path, or XDG_xxx_DIR="/yyy", where /yyy is an # absolute path. No other format is supported. # XDG_DESKTOP_DIR="$HOME/Escritorio" XDG_DOWNLOAD_DIR="$HOME/Descargas" XDG_TEMPLATES_DIR="$HOME/Plantillas" XDG_PUBLICSHARE_DIR="$HOME/Público" XDG_DOCUMENTS_DIR="$HOME/Documentos" XDG_MUSIC_DIR="$HOME/Música" XDG_PICTURES_DIR="$HOME/Imágenes" XDG_VIDEOS_DIR="$HOME/VÃdeos" Also just realized that it should be SDL_GetVideosPath, not SDL_GetVideoPath x_X (oh well, this is nitpicking, choose whichever one is better) _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
MrTAToad
|
It is a very good idea
|
|||||||||||
|
Suggestions for more path retrieving functions for SDL |
Jonny D
|
Have you considered if it would be more appropriate as an extension library?
Jonny D |
|||||||||||
|
Re: Suggestions for more path retrieving functions for SDL |
Suggestions for more path retrieving functions for SDL |
Sik
|
2014-10-06 11:39 GMT-03:00, Jonathan Dearborn:
Well, SDL_GetBasePath and SDL_GetPrefPath are part of the core SDL2, and they're pretty much the same kind of functions, all things considered. If those can be in core SDL2, I don't see why these functions can't be in as well. They're all about retrieving system-specific paths, after all. It'd probably make even more sense to have all this functionality in PhysicsFS instead (since that library's whole purpose is to handle filesystem stuff), but eh _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Suggestions for more path retrieving functions for SDL |
Robotic-Brain
Guest
|
Sounds great!
Some Ideas: 1. To prevent the explosion of functions I would suggest a ENUMed function like this: SDL_GetUserDataPath(SDL_PICTURES_PATH) Then the fallback to $HOME would be trivial (maybe a string key would be better: see next point) 2. Maybe even combine it with SDL_GetPrefPath like this: (following code intended as the general fallback method if the specified path makes no sense on the system) Pseudocode: SDL_GetUserDataPath(const char* key) { char* org; /* Set by a SDL HINT defaults to "org.libsdl.common" */ char* app; /* Set by a SDL HINT defaults to "default" */ char* configFile = SDL_GetPrefPath(org, app); return readKeyFromConfig(configFile, key); } 3. OSX has the ability to bounce the dock icon of the downloads folder if a file was added to it. Is that currently possible with SDL? If not this would be neat in conjunction with SDL_GetUserDataPath(SDL_DOWNLOADS_PATH) _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Suggestions for more path retrieving functions for SDL |
Sik
|
2014-10-07 13:56 GMT-03:00, Robotic-Brain:
I'm not sure that'd be a good idea, you want it to return the current directory according to the system settings (for example, if the user changes the location of one of the folders, the function should reflect that change accordingly without having to touch the program files at all). Also don't use this as a fallback if the program is not allowed to access the user directories either! The function should return NULL in that case, if you aren't meant to access it then don't give means to work around that. Programs should be written taking that case into account. If not they're faulty and SDL shouldn't have to care about that.
Shouldn't it be done when a file is written rather than when the function is called? (although I wouldn't be surprised if OSX just bounces automatically when it detects a file is written in that folder, that'd work correctly in most situations and be harmless when it doesn't) _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Suggestions for more path retrieving functions for SDL |
Robotic-Brain
Guest
|
Am 08.10.2014 00:45, schrieb Sik the hedgehog:
This is only intended for standard Paths the system does not know. (Like Linux systems where the Desktop Environment does not provide any "Documents" folder) If the program has no permissions at all it should return NULL of course...
No, you have to send some Cocoa notification to the system SDL would need an extra function to do that _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Suggestions for more path retrieving functions for SDL |
Sik
|
2014-10-08 9:56 GMT-03:00, Robotic-Brain:
I already accounted for that in the description: if the requested directory can't be determined (e.g. in the case of Linux the XDG configuration is not present) it resorts to looking for the home directory instead. The user is going to have a much easier time finding a file in the home directory than in some arbitrary position SDL decided to use. If it can't find the home directory either (or anything that could resemble it) then it returns NULL, but when that happens you have much bigger problems and you probably should give up on it :P
Oh OK. But yeah, that'd have to be its own function (maybe even a generic function for sending notifications to the OS in general, not necessarily filesystem-specific). _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Suggestions for more path retrieving functions for SDL |
Robotic-Brain
Guest
|
Am 09.10.2014 01:11, schrieb Sik the hedgehog:
You are still missing the point... That way you'll just litter the home directory with a bunch of files, which belong somewhere else, and the user has absolutely no control over it.. (Unless the application provides a way to change it) With my approach you need only one file in a specific place, all other paths are customizable by the user. If this configuration file is newly created you can always initialize it to $HOME. (If you don't like that: Environment vars would work too but i think they are kind of awkward to customize on most systems) Think of it like the GameController API where remapping is implemented in SDL instead of the application level _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Suggestions for more path retrieving functions for SDL |
Sik
|
Actually, thinking more about this:
2014-10-09 13:03 GMT-03:00, Sik the hedgehog:
Of course it's possible to have the configuration file not even specify all paths. Then it overrides the OS settings, but only for the paths that are defined. That'd make a lot more of sense. You're still going to have the problem of figuring out a sane default when neither are available though. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Suggestions for more path retrieving functions for SDL |
Sik
|
2014-10-09 12:29 GMT-03:00, Robotic-Brain:
If the specialized folders aren't available, that most likely means the platform doesn't have such a concept in the first place and then yes, the home directory would be the correct one. Although now I'm looking up and it seems Windows' concept of home directory isn't even remotely similar to that of *nix (in other words, on Windows you're never supposed to put anything in the home directory, it's just a holder for all the specialized folders). Ugh. Maybe we should remove the ability to retrieve the home directory and instead force programs to look for the specialized folders (still resorting to a sane default if not available).
What happens if the settings change? Should settings override the configuration file (effectively making the latter useless in most systems) or should it be the other way (effectively preventing the program from seeing the new paths)? And yes I've seen it happen - sometimes the directory gets moved elsewhere, and if the default paths are localized if you change the OS language setting the directories get renamed.
That's a different issue because the operating system doesn't provide the controller mappings (XInput controllers aside, which have a hardcoded mapping). SDL literally has no choice here. If the operating system provided the mappings, it'd have been better to let the operating system handle it instead. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
Suggestions for more path retrieving functions for SDL |
Robotic-Brain
Guest
|
Am 09.10.2014 18:05, schrieb Sik the hedgehog:
That's the intention..
If the system neither provides a "Something" folder nor has a $HOME concept, there is no way to figure anything out. In that case you would have to return NULL, and let the application ask the user how to proceed. However this should only rarely ever happen in practice.. (Thinking about it... if there is no e.g. "Images" folder the "Desktop" folder would make sense - if it exists) _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Suggestions for more path retrieving functions for SDL |
Sik
|
2014-10-09 14:10 GMT-03:00, Robotic-Brain:
The way you had worded it made it look like SDL would only look into that configuration file and nothing else :S _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Suggestions for more path retrieving functions for SDL |
Joseph Carter
|
Seems that SDL's officially supported platforms all have something
sane to fall back upon. The ones that don't are interesting embedded platforms where the app will have to figure out what to do on its own anyway. Joseph On Thu, Oct 09, 2014 at 07:10:35PM +0200, Robotic-Brain wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|