XDG dirs

[MestreLion]

This discussion started in another topic, but I guess it deserves its own

Em quinta-feira, 29 de março de 2012 15h54min09s UTC-3, Phil Bordelon escreveu:

On 03/29/2012 01:17 PM, MestreLion wrote:
> No apologies needed. You already said you were OK with those changes, and
> we agreed about *how* those changes should be presented/published/merged.
> As for *when*, it doesn't matter to me, so take your time.

I merged fix_events_translating, respect_singledir, and
translation_pt_BR.  I'm still a little leery of the XDG patches,
particularly the one that does some funny things with symlinks.

Lol, that is fine. They were the last merges in "master" for a reason ;)

There are very verbose comments in both commit messages and code about how they work, but here is some "inside info" that may help clarify a few things:

- If ~/.endgame exists, no xdg dir will be used. ever. period. I swear. :) This only affects new, fresh installs. I will also /not/ move files over to the new location. The only way for a user to "benefit" from xdg changes is to delete his current ~/.endgame dir.

- XDG_CONFIG_HOME and XDG_DATA_HOME will only be used /if they already exist/. So, if the user does not already have a ~/.config and ~/.local/share, E:S will not be the first to create them, and default ~/.endgame is used instead. XDG spec allows an app to create them (actually it /requires/ this), but I wasn't bold enough to.

- There are 2 main motivations for using xdg: first, to un-clutter the user's home dir. I don't know about you, but hate to hit CTRL+H in Nautilus and see literally /dozens/ of config dirs and files. For stuff ~/.bashrc or ~/.ssh/ it's ok, afterall this is a 20+ years tradition I won't fight against. But E:S is a desktop, modern game. All (or most) Gnome and KDE apps are already in ~/.config, no reason for E:S to act like a legacy app.

- The other reason is conformity: the package name is singularity (in Ubuntu, Debian, Fedora, Arch), the main .py file is singularity, why the config folder is ~/.endgame?

- Ok, you bought the ~/.endgame -> ~/.config/singularity idea. Now we have a problem: XDG spec enforces that only user *configuration* should be placed there. No data files, no cache files, and certainly no music files either. For that, they have a /data/ home dir. So the proper place for music is ~/.local/share/singularity/music.

- But that sucks: ~/.local/share/ is kind of an obscure dir. And user may be used to put music in E:S config dir/music. Hell, E:S even *creates* that empty dir as a "hint" for the user that he can place music files there. He will /never/ look into ~/.local/share, so creating empty dir there is useless as a hint, and users might dislike not having everything under a single dir.

Hence the symlink ;)

- Of course, if configdir/music  already exists (either at ~/.config/singularity or ~/.endgame), no symlink will be created. And again, files will /not/ be moved over. Symlink is for fresh installs only, and it is still just a hint for the proper location, like before.

- E:S will read from 3 places: "game dir"/music, "xdg_data"/music and "config dir"/music. But it will be smart enough not to read from last one if it is a symlink to the previous, to avoid duplicates in music list.

XDG conformity, 100% backward compatibility, "everything under a single dir" from user perspective, read from everywhere with no dupes. Many pros, and the only "con" I can see is the (I admit) "funny things with symlinks"
 
ML

[MestreLion]

Em quinta-feira, 29 de março de 2012 17h50min04s UTC-3, MestreLion escreveu:

- The other reason is conformity: the package name is singularity (in Ubuntu, Debian, Fedora, Arch), the main .py file is singularity, why the config folder is ~/.endgame?

And yes, this does mean that somewhere in the near future I will create a proper singularity executable, and symlink the infamous*  ./Endgame_Linux to it. And when distros adjust to the new executable, in about an year or two, delete the symlink.

* - infamous as in: how ironic it is to have a *linux-only* executable with Upper_Chars ? An why "endgame' again? This should die. You've been warned. Be prepared. :P

PS: You realize now how dangerous it is to offer commit access to strangers? There's some crazy people out there, man...

PS2: Someone has been pretty busy at bug-tracking today, huh? I hope I'm not spoiling your D&D nite :)


 

[Phil Bordelon]

On 03/29/2012 04:44 PM, MestreLion wrote:
> Em quinta-feira, 29 de março de 2012 17h50min04s UTC-3, MestreLion escreveu:
>
> - The other reason is conformity: the package name is singularity
> (in Ubuntu, Debian, Fedora, Arch), the main .py file is singularity,
> why the config folder is ~/.endgame?
>
>
> And yes, this does mean that somewhere in the near future I will create

> a proper *singularity* executable, and symlink the infamous*

> ./Endgame_Linux to it. And when distros adjust to the new executable, in
> about an year or two, delete the symlink.

No need to symlink this. Any distribution packaging the game changes
the name anyway, and anyone not running it in a distribution should
read the README. A rename is Just Fine.

> * - infamous as in: how ironic it is to have a *linux-only* executable
> with Upper_Chars ? An why "endgame' again? This should die. You've been
> warned. Be prepared. :P

Pretty sure it's just legacy from the original PyWeek code that EMH
wrote. And, after all, the game /is/ called "Endgame: Singularity."
It's not /that/ crazy. (But I'm totally fine with standardizing
everything on 'singularity.'

> PS: You realize now how dangerous it is to offer commit access to
> strangers? There's some crazy people out there, man...

And that's why git can handle crazy committers just fine :)

> PS2: Someone has been pretty busy at bug-tracking today, huh? I hope I'm
> not spoiling your D&D nite :)

I was doing that when I should be working. D&D went fine.

P

[Phil Bordelon]

On 03/29/2012 03:50 PM, MestreLion wrote:
> This discussion started in another topic, but I guess it deserves its own

I was looking over this patch again. It seems fine, for the most part, but
I'm pretty sure that in the second patch, code/g.py, line 266-267 should be:

if os.path.isdir(xdg_music):
music_paths.append(xdg_music)

rather than the current if() on xdg_data_home. We expect xdg_music to
exist, after all, and make a symlink to it, not its parent.

P

[Mestre Lion]

That was intentional.

The rationale is that, since you were a bit leery on using standard XDG dirs, I took the most conservative approach:

~/.local/share/singularity/music is /created/ only if its parent ~/.local/share already exists. This way E:S will not be the first to use this path, but it will benefit from it /if/ user already has other compliant software in it.

So the if() in 266-267 is not about testing if it exists, but rather deciding if it /should/ exist (and, eventually, if prefs/music should be created as a symlink to it). The logic that actually tests its existence and create it if necessary is in line 282 and 301-309.

A similar approach was taken about the prefs dir (the previous commit): ~/.config/singularity is created only if ~/.config already exists. It is a conservative approach so E:S won't ever be the first to create the XDG infrasctructure, it will only comply with it in case that structure already exists.

And remember: if ~/.endgame (and ~/.endgame/music) already exists, they will be used. In this case, no xdg or symlinking or anything. So old users will not be affected at all. And new users will thank us for nor cluttering his home with an additional hidden dir.

ML

[Phil Bordelon]

On 05/15/2012 11:07 PM, Mestre Lion wrote:
> That was intentional.

Yeah. The problem was that I was just looking at the diff rather than
the whole source file, where it's made clear that the musicdir gets created
later on. Oops. Sorry about that.

Feel free to push the XDG stuff to master.

P