Re: Extending xdg-user-dirs
On Thu, 2016-03-10 at 13:55 -0800, Cosimo Cecchi wrote: > Hey Bastien, > > On Wed, Mar 9, 2016 at 2:06 AM, Bastien Nocera > wrote: > > I commented on the xdg-user-dirs patches. It's mostly fine, but > > still > > has the same problem as the first set of patches, which is going to > > be > > about organising conflicts between applications. > Thanks for the comments; I am a bit unclear how you would like to see > the current patchset change to address that. > Could you give me an example? I thought I implemented the suggestion > from your initial mail. > > > A couple of things that I'd like before merging all this: > > - verify that transifex or another system is in place to update and > > be > > reactive to new translations > I see translation commits in master, so I was assuming this worked > already. I have no idea how Alex dealt with it. > Is there anything in my patchset you think would result in a change > in that regard? No, the patchset is fine. I'm just concerned about translations not getting updated in a timely manner, or the same problem for patches for adding new sub-user-dirs. > > - a test suite, verifying that files get moved properly, get > > renamed, > > etc. as expected. > Definitely; this is something I wanted too and I will work on it > next. Right, it's a bit difficult to see whether there are bugs in your patchset without a test suite, as the changes are quite invasive. > > Other than that, I'm happy with the changes, even if the man pages > > are > > still on the short side to me. > OK, I will try to expand that too. > > Either way, since the patchset is pretty large as it is, I'd love to > be able to merge the refactors/GLib port without the new user > directories feature in the meantime. Right. As mentioned, I'd really like to see at least a basic test suite before doing that, as the GLib port is the part of the patchset that's most likely to have bugs in it. > Another thing that would greatly benefit the code is porting it to > GIO. I initially didn't do that to reduce the churn and introduce a > dependency on GObject, but in retrospect I don't see why not - > practically speaking everyone shipping GLib already also ships > GObject/GIO. > > What do you think? I personally wouldn't mind, but bear in mind that you'll likely want to disable the gvfs extension point to avoid possible races/hangs waiting for the gvfs service on session startup. Again, easier to review and ack with a test suite. Cheers ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending xdg-user-dirs
Hey Bastien, On Wed, Mar 9, 2016 at 2:06 AM, Bastien Nocera wrote: > I commented on the xdg-user-dirs patches. It's mostly fine, but still > has the same problem as the first set of patches, which is going to be > about organising conflicts between applications. > Thanks for the comments; I am a bit unclear how you would like to see the current patchset change to address that. Could you give me an example? I thought I implemented the suggestion from your initial mail. A couple of things that I'd like before merging all this: > - verify that transifex or another system is in place to update and be > reactive to new translations > I see translation commits in master, so I was assuming this worked already. Is there anything in my patchset you think would result in a change in that regard? - a test suite, verifying that files get moved properly, get renamed, > etc. as expected. > Definitely; this is something I wanted too and I will work on it next. Other than that, I'm happy with the changes, even if the man pages are > still on the short side to me. > OK, I will try to expand that too. Either way, since the patchset is pretty large as it is, I'd love to be able to merge the refactors/GLib port without the new user directories feature in the meantime. Another thing that would greatly benefit the code is porting it to GIO. I initially didn't do that to reduce the churn and introduce a dependency on GObject, but in retrospect I don't see why not - practically speaking everyone shipping GLib already also ships GObject/GIO. What do you think? Thanks, Cosimo ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending xdg-user-dirs
On Tue, 2016-03-08 at 16:11 -0800, Cosimo Cecchi wrote: > Hi Bastien, > > I am still interested in pursuing this, and possibly adopting > upstream maintenance of the xdg-user-dirs and xdg-user-dirs-gtk > modules. > My branches still apply as they are, as no other changes went in git > master in the meantime, and should address your comments. > > Please let me know if there's anything else I can do to move this > discussion forward. The mail slipped through the cracks when I was away. > Thanks, > Cosimo > > On Thu, Jan 29, 2015 at 4:45 AM, Cosimo Cecchi om> wrote: > > Hey Bastien, > > > > Picking this up again... > > > > On Tue, Apr 1, 2014 at 10:42 PM, Bastien Nocera > > wrote: > > > Hey, > > > > > > On Mon, 2014-03-03 at 16:42 -0800, Cosimo Cecchi wrote: > > > > > > This diff to the spec isn't very clear: > > > https://github.com/cosimoc/xdg-user-dirs/commit/29c89e42ec784fd00 > > > 075b44cdfa459de7aecb1a9 > > > > > > It's really not very clear that the extension files are in a > > > sub-directory. > > > > > That is not the diff to the spec; there is unfortunately no "spec" > > for this. That commit changes the manpage of the xdg-user-dirs- > > update command. > > I added a commit to make the subdirectory more explicit. > > > > > > Use cases: > > > > * An application (e.g. a sound recorder) wants to save > > > a file > > > > in a subdirectory of $XDG_MUSIC_DIR. Another sound > > > recorder > > > > wants to save files in the same subdirectory, and > > > doesn't want > > > > to worry about the translations for each language to be > > > in > > > > sync. > > > > > > How can sound recorder #2 rely on #1 being present, and having > > > installed > > > the directory file with the right name? Should common directories > > > be > > > shipped in xdg-users-dir? > > [snip] > > > > > > We think that, to avoid inter-application dependency, and > > > cluttering > > > those top-level dirs with more slightly different versions of the > > > same > > > directory, we should ship the most common directories in xdg- > > > users-dir > > > directly. > > > > > > I hope this is clear enough so we can carry the discussion > > > forward a > > > little. > > It is, thanks; I added a predefined directory now for backgrounds. > > I didn't add other directories yet, but that's easy for people to > > do once the infrastructure is in place. > > One small complication is whether xdg-user-dirs-update should > > always create those directories; I believe it shouldn't, and > > applications will have to ensure those directories exist anyway. I > > changed the tool not to automatically create those directories that > > are defined by .desktop files, which I think makes sense. > > > > Here's updated branches for my work: > > https://github.com/cosimoc/xdg-user-dirs/tree/wip/user-directories > > https://github.com/cosimoc/xdg-user-dirs-gtk/tree/wip/user-director > > ies > > https://github.com/cosimoc/glib/tree/wip/user-directories I commented on the xdg-user-dirs patches. It's mostly fine, but still has the same problem as the first set of patches, which is going to be about organising conflicts between applications. A couple of things that I'd like before merging all this: - verify that transifex or another system is in place to update and be reactive to new translations - a test suite, verifying that files get moved properly, get renamed, etc. as expected. Other than that, I'm happy with the changes, even if the man pages are still on the short side to me. Cheers ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending xdg-user-dirs
Hi Bastien, I am still interested in pursuing this, and possibly adopting upstream maintenance of the xdg-user-dirs and xdg-user-dirs-gtk modules. My branches still apply as they are, as no other changes went in git master in the meantime, and should address your comments. Please let me know if there's anything else I can do to move this discussion forward. Thanks, Cosimo On Thu, Jan 29, 2015 at 4:45 AM, Cosimo Cecchi wrote: > Hey Bastien, > > Picking this up again... > > On Tue, Apr 1, 2014 at 10:42 PM, Bastien Nocera wrote: > >> Hey, >> >> On Mon, 2014-03-03 at 16:42 -0800, Cosimo Cecchi wrote: >> >> This diff to the spec isn't very clear: >> >> https://github.com/cosimoc/xdg-user-dirs/commit/29c89e42ec784fd00075b44cdfa459de7aecb1a9 >> >> It's really not very clear that the extension files are in a >> sub-directory. >> > > That is not the diff to the spec; there is unfortunately no "spec" for > this. That commit changes the manpage of the xdg-user-dirs-update command. > I added a commit to make the subdirectory more explicit. > > > Use cases: >> > * An application (e.g. a sound recorder) wants to save a file >> > in a subdirectory of $XDG_MUSIC_DIR. Another sound recorder >> > wants to save files in the same subdirectory, and doesn't want >> > to worry about the translations for each language to be in >> > sync. >> >> How can sound recorder #2 rely on #1 being present, and having installed >> the directory file with the right name? Should common directories be >> shipped in xdg-users-dir? >> > > [snip] > >> >> We think that, to avoid inter-application dependency, and cluttering >> those top-level dirs with more slightly different versions of the same >> directory, we should ship the most common directories in xdg-users-dir >> directly. >> >> I hope this is clear enough so we can carry the discussion forward a >> little. >> > > It is, thanks; I added a predefined directory now for backgrounds. I > didn't add other directories yet, but that's easy for people to do once the > infrastructure is in place. > One small complication is whether xdg-user-dirs-update should always > create those directories; I believe it shouldn't, and applications will > have to ensure those directories exist anyway. I changed the tool not to > automatically create those directories that are defined by .desktop files, > which I think makes sense. > > Here's updated branches for my work: > https://github.com/cosimoc/xdg-user-dirs/tree/wip/user-directories > https://github.com/cosimoc/xdg-user-dirs-gtk/tree/wip/user-directories > https://github.com/cosimoc/glib/tree/wip/user-directories > > Thanks, > Cosimo > ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending xdg-user-dirs
Hey Bastien, Picking this up again... On Tue, Apr 1, 2014 at 10:42 PM, Bastien Nocera wrote: > Hey, > > On Mon, 2014-03-03 at 16:42 -0800, Cosimo Cecchi wrote: > > This diff to the spec isn't very clear: > > https://github.com/cosimoc/xdg-user-dirs/commit/29c89e42ec784fd00075b44cdfa459de7aecb1a9 > > It's really not very clear that the extension files are in a > sub-directory. > That is not the diff to the spec; there is unfortunately no "spec" for this. That commit changes the manpage of the xdg-user-dirs-update command. I added a commit to make the subdirectory more explicit. > Use cases: > > * An application (e.g. a sound recorder) wants to save a file > > in a subdirectory of $XDG_MUSIC_DIR. Another sound recorder > > wants to save files in the same subdirectory, and doesn't want > > to worry about the translations for each language to be in > > sync. > > How can sound recorder #2 rely on #1 being present, and having installed > the directory file with the right name? Should common directories be > shipped in xdg-users-dir? > [snip] > > We think that, to avoid inter-application dependency, and cluttering > those top-level dirs with more slightly different versions of the same > directory, we should ship the most common directories in xdg-users-dir > directly. > > I hope this is clear enough so we can carry the discussion forward a > little. > It is, thanks; I added a predefined directory now for backgrounds. I didn't add other directories yet, but that's easy for people to do once the infrastructure is in place. One small complication is whether xdg-user-dirs-update should always create those directories; I believe it shouldn't, and applications will have to ensure those directories exist anyway. I changed the tool not to automatically create those directories that are defined by .desktop files, which I think makes sense. Here's updated branches for my work: https://github.com/cosimoc/xdg-user-dirs/tree/wip/user-directories https://github.com/cosimoc/xdg-user-dirs-gtk/tree/wip/user-directories https://github.com/cosimoc/glib/tree/wip/user-directories Thanks, Cosimo ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending xdg-user-dirs
Hey, On Mon, 2014-03-03 at 16:42 -0800, Cosimo Cecchi wrote: > Hi all, This diff to the spec isn't very clear: https://github.com/cosimoc/xdg-user-dirs/commit/29c89e42ec784fd00075b44cdfa459de7aecb1a9 It's really not very clear that the extension files are in a sub-directory. > Use cases: > * An application (e.g. a sound recorder) wants to save a file > in a subdirectory of $XDG_MUSIC_DIR. Another sound recorder > wants to save files in the same subdirectory, and doesn't want > to worry about the translations for each language to be in > sync. How can sound recorder #2 rely on #1 being present, and having installed the directory file with the right name? Should common directories be shipped in xdg-users-dir? > > * A photo booth application wants to save pictures to a webcam > snaps subdirectory of $XDG_PICTURES_DIR. An "user properties" > settings panel in the desktop environment allows to pick an > avatar picture through a file chooser, which should default to > the webcam snaps place. > > > There's a bunch of similar cases, which you can find in this > bug [1] where this message originates from. The original bug is about backgrounds and discussing it with David Faure and Ryan, we wondered what would happen if the KDE wallpaper panel was to make it create a ~/Pictures/Wallpapers and the GNOME one made it create a ~/Pictures/Backgrounds? How do we avoid the directories being filled up with gunk from running different desktop environments, or, if we use the same file shipped by xdg-users-dir, do we decide whether it should be called Backgrounds or Wallpapers? We think that, to avoid inter-application dependency, and cluttering those top-level dirs with more slightly different versions of the same directory, we should ship the most common directories in xdg-users-dir directly. I hope this is clear enough so we can carry the discussion forward a little. Cheers ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending xdg-user-dirs
Hi all,
I went ahead and wrote an implementation of my proposal, which you can now
find here
- https://github.com/cosimoc/xdg-user-dirs/tree/wip/user-directories
- https://github.com/cosimoc/xdg-user-dirs-gtk/tree/wip/user-directories(updates
to the GTK version of the tool)
- https://github.com/cosimoc/glib/tree/wip/user-directories (adds new GLib
API)
One caveat is in order to make this possible, I essentially rewrote
xdg-user-dirs to use GLib APIs - I didn't want to parse keyfiles manually.
So you'll need GLib to build the tool... I don't think that'll be a big
deal, since GLib is a build dependency for a lot of things these days.
Comments welcome!
Cosimo
On Wed, Jan 15, 2014 at 11:00 AM, Cosimo Cecchi wrote:
> Hi all,
>
> I'd like to propose an extension to the current xdg-user-dirs mechanism to
> make it possible to create application-specific subdirectories in user
> dirs, which are subject to the same translation rules applied to their
> parents.
>
> Use cases:
> * An application (e.g. a sound recorder) wants to save a file in a
> subdirectory of $XDG_MUSIC_DIR. Another sound recorder wants to save files
> in the same subdirectory, and doesn't want to worry about the translations
> for each language to be in sync.
>
> * A photo booth application wants to save pictures to a webcam snaps
> subdirectory of $XDG_PICTURES_DIR. An "user properties" settings panel in
> the desktop environment allows to pick an avatar picture through a file
> chooser, which should default to the webcam snaps place.
>
> There's a bunch of similar cases, which you can find in this bug [1] where
> this message originates from.
>
> Implementation:
> We need a way for applications to describe and own those subdirectories
> inside XDG user dirs. I think this could be as simple as the application
> dropping a desktop file on installation, in a well-known directory - for
> example $XDG_DATA_DIRS/xdg-user-dirs. Such a desktop file would have a
> structure like
>
> [Directory]
> Name=Webcam Snapshots
> Name[it]=Scatti dalla Webcam
> Name[es]=...
> Name[fr]=...
> Parent=$XDG_PICTURES_DIR
> Icon=icon-name-from-theme (optional)
>
> An utility like xdg-user-dirs-update would then take care of renaming such
> directories early at login, together with their parents. Toolkit support
> would be achieved with a function that returns the full path of a
> subdirectory given the basename of its desktop file descriptor.
>
> In the example above, if the file is called "gnome-webcam.desktop", a
> GNOME application would call g_get_user_special_dir_for_id
> ("gnome-webcam.desktop"); which would return "$HOME/Pictures/Webcam
> Snapshots" in English and "$HOME/Immagini/Scatti dalla Webcam" in Italian.
>
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=712245
>
> Feedback welcome!
> Cosimo
>
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending xdg-user-dirs
Le Wed, 15 Jan 2014 23:40:44 +0100, David Nečas a écrit : > On Wed, Jan 15, 2014 at 10:29:49PM +0100, Alexandre Franke 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. > > In my experience, with users ranging from completely clueless to > system programmers, people do not organise user-created files by > type. Never. Really never. That's true. It is why I use play lists and have a central place for them. That concept can be expanded to any kind of files like comics, or whatever collection have an user. FVWM-Crystal have a preference file where the users can put the path to the root of their media files collections and associate them with a type. It is 4 types for now, audio, video, cdrom and dvd. It is a function associated with them that will automatically generate the play lists into a hidden tree on which the user have no control. It is also a menu that permit to load these play lists, and to archive basic management of these play lists. That management is coupled to another Playlist tree, which is permanent and visible (~/Playlists/*), and on which the users have full control, either from the menu or by doing whatever with the files in that visible tree. Dominique > > On the extremely clueless end of the spectrum they may not be able to > keep any coherent organisation, but if they are able they organise > created files by something I would call ‘projects’. A project is a > group of files that are united by purpose, not type. This is a strong > force binding the files together conceptually. When you create a > presentation, you want the various source pieces, documents, data, > graphics, multimedia, references, code and whatever in one place (at > least conceptually, if not physically). Etc. > > IMO ‘I am working on this project now’ is a workflow that needs to be > supported better for user-created files. Detailed classification by > type and application is harmful in this case and should not be > encouraged for content creation/editing applications. > > Someone may record sound or take pictures pictures randomly. But if > the activity has a purpose, it is more important that ‘I am recording > BECAUSE...’ than ‘I am recording BY THE MEANS OF...’. > > Just my 0.02 €. > > Yeti > > ___ > xdg mailing list > xdg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending xdg-user-dirs
Le Wed, 15 Jan 2014 22:29:49 +0100, Alexandre Franke a écrit : > On Wed, Jan 15, 2014 at 8:00 PM, Cosimo Cecchi > wrote: > > Hi all, > > Hey, > > > Feedback welcome! > > Music player usually get all the content of the Music directory and > then grab metadata to present the tracks filtered by > artists/albums/whatever. This is relevant for your virtual disc > collection, not so much for the notes you record with your sound > recorder, or the multi-track recordings you're working on with your > band in a DAW. I don't think it is relevant even for all music players. They all have their own way to deal with the files they can read, and sometime it is so different it is not even possible to have the same directories for their play lists. Some players use directly the play lists, other manage their own internal play lists in some kind of private database, that from both audio files like .mp3 and play list files like .m3u. You may also have to deal with problems like do I add the file in the current play list queue, or at the top of the play list and play it directly? Each player have its own way to deal with that. Some don't care and impose a policy, some have a preference setting, others use command line options, and some have both a preference setting and command line options. Another issue is that play lists can be about audio or video. So where is the best place to put them? Video/Playlists and Musique/Playlists, or Playlists/Video and Playlists/Musique? It is Playlists/* in FVWM-Crystal, which made possible to have play list in one central place for every thing. Dominique ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending xdg-user-dirs
On Wed, Jan 15, 2014 at 10:29:49PM +0100, Alexandre Franke 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. In my experience, with users ranging from completely clueless to system programmers, people do not organise user-created files by type. Never. Really never. On the extremely clueless end of the spectrum they may not be able to keep any coherent organisation, but if they are able they organise created files by something I would call ‘projects’. A project is a group of files that are united by purpose, not type. This is a strong force binding the files together conceptually. When you create a presentation, you want the various source pieces, documents, data, graphics, multimedia, references, code and whatever in one place (at least conceptually, if not physically). Etc. IMO ‘I am working on this project now’ is a workflow that needs to be supported better for user-created files. Detailed classification by type and application is harmful in this case and should not be encouraged for content creation/editing applications. Someone may record sound or take pictures pictures randomly. But if the activity has a purpose, it is more important that ‘I am recording BECAUSE...’ than ‘I am recording BY THE MEANS OF...’. Just my 0.02 €. Yeti ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending xdg-user-dirs
Hi Alexander, thanks for your comments. On Wed, Jan 15, 2014 at 1:29 PM, Alexandre Franke < alexandre.fra...@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 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending xdg-user-dirs
On Wed, Jan 15, 2014 at 9:29 PM, Alexandre Franke wrote: > On Wed, Jan 15, 2014 at 8:00 PM, Cosimo Cecchi > wrote: >> Hi all, > > Hey, > >> Feedback welcome! > > Music player usually get all the content of the Music directory and > then grab metadata to present the tracks filtered by > artists/albums/whatever. This is relevant for your virtual disc > collection, not so much for the notes you record with your sound > recorder, or the multi-track recordings you're working on with your > band in a DAW. > > 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. > > 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 can't comment on the rest but this part should be handled with simple mime type support. If the app can recognize guitar tabs files, it'll know what they are - if it can't, it should ignore them. > > -- > Alexandre Franke > ___ > xdg mailing list > xdg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending xdg-user-dirs
On Wed, Jan 15, 2014 at 8:00 PM, Cosimo Cecchi wrote: > Hi all, Hey, > Feedback welcome! Music player usually get all the content of the Music directory and then grab metadata to present the tracks filtered by artists/albums/whatever. This is relevant for your virtual disc collection, not so much for the notes you record with your sound recorder, or the multi-track recordings you're working on with your band in a DAW. 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. 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? -- Alexandre Franke ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Extending xdg-user-dirs
Hi all,
I'd like to propose an extension to the current xdg-user-dirs mechanism to
make it possible to create application-specific subdirectories in user
dirs, which are subject to the same translation rules applied to their
parents.
Use cases:
* An application (e.g. a sound recorder) wants to save a file in a
subdirectory of $XDG_MUSIC_DIR. Another sound recorder wants to save files
in the same subdirectory, and doesn't want to worry about the translations
for each language to be in sync.
* A photo booth application wants to save pictures to a webcam snaps
subdirectory of $XDG_PICTURES_DIR. An "user properties" settings panel in
the desktop environment allows to pick an avatar picture through a file
chooser, which should default to the webcam snaps place.
There's a bunch of similar cases, which you can find in this bug [1] where
this message originates from.
Implementation:
We need a way for applications to describe and own those subdirectories
inside XDG user dirs. I think this could be as simple as the application
dropping a desktop file on installation, in a well-known directory - for
example $XDG_DATA_DIRS/xdg-user-dirs. Such a desktop file would have a
structure like
[Directory]
Name=Webcam Snapshots
Name[it]=Scatti dalla Webcam
Name[es]=...
Name[fr]=...
Parent=$XDG_PICTURES_DIR
Icon=icon-name-from-theme (optional)
An utility like xdg-user-dirs-update would then take care of renaming such
directories early at login, together with their parents. Toolkit support
would be achieved with a function that returns the full path of a
subdirectory given the basename of its desktop file descriptor.
In the example above, if the file is called "gnome-webcam.desktop", a GNOME
application would call g_get_user_special_dir_for_id
("gnome-webcam.desktop"); which would return "$HOME/Pictures/Webcam
Snapshots" in English and "$HOME/Immagini/Scatti dalla Webcam" in Italian.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=712245
Feedback welcome!
Cosimo
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
