On Sun, Jan 8, 2012 at 12:20 PM, Kevin Krammer <[email protected]> wrote: > You seem to have replied only to me, not to the list. > > On Sunday, 2012-01-08, you wrote: >> On Fri, Jan 6, 2012 at 8:53 AM, Kevin Krammer <[email protected]> wrote: >> > How would that improve upon any of the holdback reasons you cited above? >> > >> > Is there any public statement of developers in the groups "indifferent" >> > or "uncertain" that they would support a fixed location but cannot be >> > bothered to read a single environment variable? >> >> Yea, the simple fact that they don't do it. > > I am afraid I don't get that. What does "it" refer to? > Making a public statement? I am not sure not making a public statement in > favor of something can be counted as an implicit public statement in favor of > something.
I mean that they don't use the environment variables. >> It might seem trivial, but >> to programmers every additional adjunct is another maintenance issue. >> With XDG base directory standard it means eiterh rolling my own code >> or having dependency on an external library. > > Hmm. I haven't done any application with just low level APIs but reading an > environment variable and a string comparison seems indeed rather trivial to > me. Though I can only speak for languages I've used so far, e.g.C/C++, Java, > Python. Might be more complicated elsewhere. Yea, it's not that complicated to implement. That's true. But it is a bit more to take into consideration. And sometimes even a bit more can seem like a lot when it is unfamiliar. Part of it is probably a perceptual issue, i.e. Am I using XDG base directory standard correctly? Aside, I also think `/etc/xdg/` default is a bit of a turn off for system wide configuration. Why isn't it just `etc/` ? >> By using a fixed path, >> the code need not have to worry about any of that. Thus making it much >> easier to implement and support. > > Ok, based on the assumption that reading an environment variable could be > difficult the question is why don't these application developer just hardcode > $HOME/.config? > > That would always keep $HOME clean of "hidden" config files and additional go > along XDG using applications in a majority of setup without any drawback. > >> > How would the proposed inconfigurability make the location more widely >> > known? >> >> By gaining acceptance into FHS proper. FHS would have no problem >> accepting fixed locations. Indeed, at this time the standard >> explicitly designates the use of home dot files. > > Interesting thought. > >> And I disagree with the term "inconfigurability". It's would still be >> configurable, but via the file system itself, not the environment >> variables. > > True, though I find symlinks to be more tedious to switch and temporarily > override. That's a good point. > Anyway, I guess my main puzzlement is still whether developers currently not > hardcoding $HOME/.config are not doing it because there could be systems where > XDG_CONFIG_HOME points to something else. > > Cheers, > Kevin _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
