<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Alexander, thanks for your comments.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Wed, Jan 15, 2014 at 1:29 PM, Alexandre Franke <span dir="ltr"><<a href="mailto:alexandre.franke@gmail.com" target="_blank">alexandre.franke@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>More generically, user generated content and work files are not<br>
exactly the same as purchased, downloaded, or transfered (from a<br>
device) media.<br>
<br>
How do you think this should be handled? So far I've seen editing apps<br>
rely on newly created directories, usually in $HOME, but as I<br>
understand they are the ones you're trying to move into the<br>
xdg-user-dirs.<br></blockquote><div><br></div><div>I don't think xdg-user-dirs is the correct level to tackle this problem, and the goal of this proposal is not really to prevent a catch-all-media-files application (e.g. Rhythmbox) from displaying files it's not interested in (even though you could argue that an application interested in doing that could enumerate the .desktop files of my proposal with Parent=$XDG_MUSIC_DIR and filter those locations out).</div>
<div>There are better ways to fix that, which can span from providing easy access to metadata on where the file originated from, to applications moving away from an exposed data storage on the file system for their internal data (i.e. the MacOS approach).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another concern, which is related: how should we handle<br>
foo-but-not-really-foo data? For instance, guitar tablatures in<br>
TuxGuitar format are music-but-not-really-music since they are not<br>
intended to just be played back with a music player. With your<br>
proposal I'd say TuxGuitar could choose to create a subdirecory in<br>
Music, but how would then your music player react?<br></blockquote><div><br></div><div>I agree this would be handled by the music player in the same way it would handle e.g. a jpg cover for an album living in a subdirectory of Music, i.e. it would just be ignored.</div>
<div><br></div><div>To reiterate the point of this proposal; this is about giving a way for applications and OS components to easily identify and access a translatable subdirectory name in XDG user dirs. I don't want to solve the problem of application data storage entirely just yet ;-)</div>
<div><br></div><div>Cosimo</div></div></div></div>