Extending xdg-user-dirs

[Cosimo Cecchi]

Hi Alexander, thanks for your comments.

On Wed, Jan 15, 2014 at 1:29 PM, Alexandre Franke <
alexandre.franke at gmail.com> wrote:

>
> More generically, user generated content and work files are not
> exactly the same as purchased, downloaded, or transfered (from a
> device) media.
>
> How do you think this should be handled? So far I've seen editing apps
> rely on newly created directories, usually in $HOME, but as I
> understand they are the ones you're trying to move into the
> xdg-user-dirs.
>

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).
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).

Another concern, which is related: how should we handle
> foo-but-not-really-foo data? For instance, guitar tablatures in
> TuxGuitar format are music-but-not-really-music since they are not
> intended to just be played back with a music player. With your
> proposal I'd say TuxGuitar could choose to create a subdirecory in
> Music, but how would then your music player react?
>

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.

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 ;-)

Cosimo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20140115/da157147/attachment.html>