Hi Everyone,
I know this is very rough, but imho the folder to store the data in should be .simutrans in the home directory.
A patch is added, please feel free to comment and add it into svn trunk.
Greetings
Marcel
I thought dot-directories was for internal data, considering that they are hidden. Simutrans' per-user directory isn't quite internal, but more like "My Games" on Windows. (On Windows, the directory is also in My documents, not in AppData.) So it should be visible to the user by default, IMHO.
I don't think that dot dirs are only contains internal files. If you look at openttd, they use .openttd as well. And Linux is not Windows ;) In Windows you have thousands of (visible) folders in your home dir, but in linux you shouldn't.
But if they're not visible, how are users supposed to find them? Even if Linux users are generally more experienced with computers, is it a good idea to force them to deal with hidden directories somewhat regularly? Apart from deleting them, I don't usually deal with dot-directories (except .m2 and .gradle at times), but that may be because I don't use Linux much for desktop use.
About three years back those data were in ".simutrans". However with Ubuntu and so user came who could not find their files anymore (not to mention MAC). Thus it was moved with large consent to "simutrans".
It's a bit ironic then that Debian (and presumably Ubuntu) still use .simutrans for the official builds then!
Quote from: prissi on December 27, 2012, 11:35:13 PM
About three years back those data were in ".simutrans".
Good ;)
Quote from: prissi on December 27, 2012, 11:35:13 PM
However with Ubuntu and so user came who could not find their files anymore (not to mention MAC). Thus it was moved with large consent to "simutrans".
Hmm, that's not a valid point in my oppinion.
At first, why do you need this folder? I see a settings.xml (one don't touch that!), a default.sve (whatever it is) a maps and save dir (which you don't touch either) and at the very last a screenshot folder. Okay. I can understand that you may access the screenshot folder, but there could be a better way of doing this, e.g. put it into the picture directory and then into a subfolder called simutrans.
Second, you can make the hidden folder visible as well as the non visible ones. You write to the FAQ (I think you have one?!) that there is a folder called .simutrans and how to access/find it.
Quote from: kierongreen on December 28, 2012, 10:42:57 AM
It's a bit ironic then that Debian (and presumably Ubuntu) still use .simutrans for the official builds then!
That's really interesting ;)
Regards
Quote from: mhubuntu on December 28, 2012, 10:45:37 AM
At first, why do you need this folder? I see a settings.xml (one don't touch that!), a default.sve (whatever it is) a maps and save dir (which you don't touch either) and at the very last a screenshot folder. Okay. I can understand that you may access the screenshot folder, but there could be a better way of doing this, e.g. put it into the picture directory and then into a subfolder called simutrans.
Second, you can make the hidden folder visible as well as the non visible ones. You write to the FAQ (I think you have one?!) that there is a folder called .simutrans and how to access/find it.
It is, or at least was, also a place to put addons and scenarios without requiring administrator privileges. (Perhaps also pak sets, I'm not sure.) We could write a FAQ entry, but it's easier for us and the players if the directory isn't hidden in the first place.
Besides, if the directory is given a dot on *nix, then it should be moved from My documents to AppData on Windows for the same reasons. But AppData is even more hidden, and perhaps less likely to be backed up.
One does need to be able to access this folder: it is useful to be able to download/upload saved games, and to be able to download height maps. I agree with Ters and Prissi, and suggest that the default for Debian be changed, too.
Is there some guideline somewhere for how per-user data should be saved on *nix? FHS doesn't seem to go into detail there.
Why not allowing both options indead so everyone is happy? :)
We can allways check for the "~/simutrans", if it doesn't exist, check for "~/.simutrans" and if none of them exist, use and create the first one
Quote from: Markohs on December 28, 2012, 01:55:42 PM
Why not allowing both options indead so everyone is happy? :)
We can allways check for the "~/simutrans", if it doesn't exist, check for "~/.simutrans" and if none of them exist, use and create the first one
I like this ;)
Here is a simple patch for this.
On the first check it worked.
Btw. why do you use sprintf and don't use std::string as you are using c++ anyway. Would spare you some buggy strcpy and possible segfaults.
Regards
An often cited reason for not using the standard C++ library to it's fullest is that Simutrans still targets platforms with an inferior/incomplete implementation of it. Another popular reason is full control of memory allocations.
Third reason is that std::string did not exist widely when large parts of simutrans were written. Before MSVC there was no support at all, if my memory serves me right. Simutrans has for anything really length critical proper classes cbuffer_t and plainstring.
Similar to not using gettext for translations: do not forget what the state of software development was 10 years ago (when people had 64 MB of main memory and thus no space for lots of libaries). A modern open source simutrans would obviously reley on different libaries; in fact it may even be written in Java.
Back to topic: Allow both directories seems like a good compromise.
In fact FHS goes into detail and requires a .dot directory http://www.pathname.com/fhs/pub/fhs-2.3.html#HOMEUSERHOMEDIRECTORIES How can I change this to the Debian/Ubuntu default on compile time without patching? I want to make an FHS compatible openSUSE package.
Quote from: Mailaender on December 28, 2012, 09:35:34 PM
How can I change this to the Debian/Ubuntu default on compile time without patching? I want to make an FHS compatible openSUSE package.
opensuse uses rpmbuild, where you can serve patches. Just use my patch (if you think it's good) and tell rpmbuild to use it, then everything should be fine ;)
Quote from: prissi on December 28, 2012, 09:27:27 PM
in fact it may even be written in Java.
I hope you are kidding ;)
At compile time you can run patch before compiling ... Or you have an init script which creates "~/.simutrans" before starting simutrans for the first time. The patch discussed then in the other forum would use ./simutrans then as preferred location.
Maybe you should just add a switch in the Makefile instead of relying on hard-coded directories and magic behavior.
Let's do remember to keep this conversation civil, please. No "religious" wars, please! While it's civil right now, there are some comments I consider borderline.
Quote from: Mailaender on December 28, 2012, 09:35:34 PM
In fact FHS goes into detail and requires a .dot directory http://www.pathname.com/fhs/pub/fhs-2.3.html#HOMEUSERHOMEDIRECTORIES (http://www.pathname.com/fhs/pub/fhs-2.3.html#HOMEUSERHOMEDIRECTORIES) How can I change this to the Debian/Ubuntu default on compile time without patching? I want to make an FHS compatible openSUSE package.
That's not "in detail". What about user specific
non-configuration files? The way I see it, there's only one configuration file in Simutrans' user directory, much of the rest are more comparable to Libreoffice documents.
Might be a matter of taste and habit then. However all the games I currently have installed (including steam on Linux) put their stuff in a "hidden" folder because users demanded it. I press [ALT] + [.] on KDE dolphin and there they are without junking the folders I work 90% of the time. In fact as a Windows user I also hate it when application put savegames or maps into my documents which I don't need to see in the explorer so I manually hide them. Therefore I decided to patch the openSUSE package as Debian/Ubuntu does. This is not meant to rude. You can just save us some work by incorporating this patch. :)
Or load it from the main simuconf file. That way distributions can choose which method without having to apply patches to the source.
Autodetecting whether to use ~/.simutrans or ~/simutrans seems reasonable to me to ensure compatibility with existing names (which may vary depending on current build).
That combined with a revised directory structure for debian, and maybe others (shell script /usr/games/simutrans which would run the binary /usr/lib/games/simutrans with directory /usr/share/games/simutrans/ - this sounds convoluted but /usr/share should only be data otherwise I'd have put the binary there) should in theory remove the need for Linux distributions of simutrans to have patches applied.
As to whether simutrans or .simutrans is better - well, I think the argument could run and run on that one - balance a cluttered directory vs easy access. The filing system standard is quite clear that .simutrans should be used - other games with saved games do this (or even hide it further under .local/share/<appname> for example - .local/share/ should be for data files and .config/ for config files under this standard). It's all very well saying simutrans stores data that needs to be easily accessible, but if every game adopted the same attitude a users home directory could have large numbers of directories. There is an argument for saying that there should be a ~/games directory or whatever, but that's not ours to fight.
Incidentally, windows has it's own problems over directory locations (http://www.rockpapershotgun.com/2012/01/23/stop-it-put-save-games-in-one-place/).
Quote from: kierongreen on December 28, 2012, 11:07:46 PMOr load it from the main simuconf file. That way distributions can choose which method without having to apply patches to the source.
This way even the end user can decide. Steam solved it this way, too. Default to ~/.steam and ~/.local/share/Steam/ but expose this configuration and have it changeable via the settings GUI.
I just put everything in ~/simutrans (executable and all) so I can update it without root access (or anything like that).
Quote from: Mailaender on December 28, 2012, 11:14:37 PM
This way even the end user can decide. Steam solved it this way, too. Default to ~/.steam and ~/.local/share/Steam/ but expose this configuration and have it changeable via the settings GUI.
Where does it store the setting where it store it's settings?
The settings are always stored to ~/.steam according to FHS. You can only decide where to put game content (~/.local/share/Steam/ by default, was ~/Steam before).
As a Linux user, I do not want to see my home directory full of files or unsorted directories. but I cannot leave many user config files or save files. And these less important files should be hided. And most Linux programs just save the config files or directory in hide. That will make users feel better, and the personal config files will not be remove easily.
For some Linux newbies, I think the best way is teaching them how to use Linux and fellow the Linux/Unix rules. If just leave them with the directory named simutrans but not .simutrans, they may leave the game when they may think this directory cannot be sorted nor renamed after learning some Linux knowledge.
I suggest that make a simple personal config file like ~/.simutransrc similar as the simconf.tab when start the game first time. And this file contains some user config, like the saving directory of the game. The simplest coding way may be just copying the simconf.tab to ~/ and rename it as hided, and loading the differences between user config and the default when the game starts.
I am also pro /.simutrans. I said this as it was changed, but the majority was against me. It would be nice to be able to choose this again.
If an uncluttered home directory is the goal, moving files out of the simutrans directory into the home directory seems the wrong choice, even if it is hidden.
Quote from: Ters on January 25, 2013, 07:43:34 PM
If an uncluttered home directory is the goal, moving files out of the simutrans directory into the home directory seems the wrong choice, even if it is hidden.
But if the user config directory is hidden, and someone do not want it to be hidden, he/she can just make an visible soft link to it. But it is not possible to make that backward.
Quote from: zcchen on January 26, 2013, 05:55:21 AM
But if the user config directory is hidden, and someone do not want it to be hidden, he/she can just make an visible soft link to it. But it is not possible to make that backward.
I wan't refererring to the directory, but the idea of moving simutrans.tab out of the Simutrans directory and into the home directory as .simutransrc (and, I assume, also hide the Simutrans directory).
Uh.
You have '-use_workdir' and '-singleuser' command line parameters.
just write appropriate shell script and use it.
Quote from: Ters on January 25, 2013, 07:43:34 PM
If an uncluttered home directory is the goal, moving files out of the simutrans directory into the home directory seems the wrong choice, even if it is hidden.
I have 119 automatically generated directories of different applications in my home directory, 118 apps created directories with dot as first character (that means hidden directories) and 1 (=Simturans !) a visible directory.
Do you think I would like to have all the 119 doing that? :o
Quote from: paco_m on January 26, 2013, 08:57:48 PM
I have 119 automatically generated directories of different applications in my home directory, 118 apps created directories with dot as first character (that means hidden directories) and 1 (=Simturans !) a visible directory.
Do you think I would like to have all the 119 doing that? :o
Why are you quoting me on that? Because you agree that having 236 hidden files and directories is a step back from 119 hidden directories?
As for the 118 programs that create hidden directories, how many of them put files users are encouraged to download, hand edit, upload or may want to watch in there?