Re: [kde-linux] KGet: "My Documents"
- Date: Fri, 27 Apr 2012 13:29:33 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde-linux] KGet: "My Documents"
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
>> 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
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
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
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.
More info: http://www.kde.org/faq.html.