[kde-linux] KGet: "My Documents"

[Duncan]

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