James Tyrer posted on Fri, 27 Apr 2012 04:23:10 -0700 as excerpted: > On 04/12/2012 01:47 PM, Duncan wrote: >> James Tyrer posted on Wed, 11 Apr 2012 21:04:01 -0700 as excerpted: >> >>>> Presumably, kget is using the documents xdg var instead of downloads, >>>> I'd guess because the downloads var was introduced after kget was >>>> already using the documents setting, the one that would have made the >>>> most sense if there wasn't yet a specific downloads setting. >>>> >>> What is "downloads var"? >> >> XDG_DOWNLOAD_DIR variable >> > Do downloads really belong in: "/var"?
I'm honestly not sure if that's a joke or a question, but when I wrote the above, I /thought/ it was obvious that "var" was short for "variable", even more so after specifically stating that I was referring to the XDG_DOWNLOAD_DIR /variable/. Indeed, nothing to do with /var at all and it couldn't have been farther from my mind at the time I wrote that, or I'd have used the leading slash, /var, not simply var. I guess it isn't so transparently obvious after all, tho hopefully it is at least in hindsight. (Either that or you're joking with the /var reference and I'm falling for it big time!) >>> KGet has had this new feature added since XDG-User-Dirs had a Download >>> directory. >> Well, it's working with some of them, the ones listed in the >> desktoppaths kcontrol module. Did you confirm whether it obeys the >> XDG_DOCUMENTS_DIR/ documents setting, > > Yes, it does. Well, that's something, then. =:^) > I previously got rid of this by manually editing the configuration files > but now it came back and I can't get rid of it. Could it be in the code > somewhere. Does KDE have NO standards at all? I'd guess it's in the code as a default. You can point it elsewhere, but you can't remove it or the default will reappear. > The reason that this is probably a bug is that it does not show proper > KDE behavior, that should be common to all apps, where the presence of > the local configuration file overrides the global file. I have simply > not been able to find which file contains the: "My Documents" string. As I said, that's probably a coded "reasonable" default, in case the config file doesn't point it elsewhere. But from your description, it does appear that there's no getting rid of that choice (without patching it out of the code); you can only point it elsewhere if you don't like where it points by default. > Note that I do not file bug reports anymore. I do not want to put up > with any further abuse from developers. I feel that I am due an > apology. Having seen a bit of the history of that, I understand your viewpoint. However, I don't necessarily agree. In fact, they probably feel if anything, you owe them one. After all, they're the ones doing the apps and "he who codes, decides", so they get to decide, and they simply happen to disagree with you. And unfortunately, it doesn't appear that you're willing to simply agree to disagree and let them do with their app(s) as they will, either forking or moving on to something better if you actually find them /that/ wrong. Given that, I guess not filing the bug reports is probably the wise decision, since it would likely lead only to additional friction to no good end for either party, but of course that means if you want it changed, you'll either have to do your own local patching (making the patches available elsewhere or not), wait for them to come to the same conclusions on their own... and it might be a rather long wait, or move on to something else. Here, as I said, I don't use that app. But if I did, given that I rather hate the "My Documents" type naming myself, I may well create a patch if I had to to rid myself of it. I don't claim to be a coder, but I can and have made patches occasionally, and fiddled them until they worked. (I retain just enough pascal from college and the principles are close enough to C/C++ that I can often get it to work, if I hack at it long enough.) What's nice is that with gentoo/kde, once I have the patch created, I can simply drop it in a particular location (/etc/portage/patches/gentoo-category/pkgname/) and have portage automatically detect the patch and try to apply it on every update from then on, no further worries on my part until the code changes enough that the patch no longer applies and an update fails at the patching step, at which point I can go in and see why, updating or dropping my patch as necessary. I currently have two patches against superkaramba (bugs filed but nobody's looked at them, I think superkaramba has no current kde maintainer at this point), one against gwenview (just changing the default zoom-step from 100% to 5% at a time, not filed upstream), and one against kdelibs (this one actually undoes part of a gentoo patch to upstream, where I find the upstream version more convenient). Save for the last one, easy to find since I could simply read and revert part of the gentoo patch, all of them are patches where I was simply able to grep the sources, look at the hits I got and read a bit around them, then make the changes I wanted and try it, changing a bit more if necessary and trying again, until it worked. Thus, if I were in your shoes, I may indeed grep my documents in the kget sources, and see what I could do with what I came up with. I've little doubt that were it sufficiently irritating enough, I'd have the motivation to track it down and create the necessary patches to do what I thought needed done, for me, because I'm already doing that in the above cases, and keeping the ability to ultimately patch the code for my own use where necessary is in fact one of the big reasons I run all freedomware! =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
