Extending xdg-user-dirs

[Bastien Nocera]

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 <hadess at hadess.net>
> 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