[kde-linux] Kget "My Downloads" [Is this MS Windows?]

[Duncan]

James Tyrer posted on Tue, 23 Apr 2013 11:16:55 -0700 as excerpted:

> No, hard coding as in being in the code and not something that changes
> with the outside world.  It is a string literal in the i18n function.
> The point here is that it does not conform to the directory name for
> $XDG_DOWNLOAD_DIR on the users system for a default and the user can not
> change it.  I still call that hard coded even if it would be changed for
> translation.

Reading the thread, it occurs to me that one solution might be to create 
a custom "l10n", that's the same as the user's normal l10n by default, 
with only the desired customizations.

That sounds like something I might do here, if the existing situation 
bothered me enough and I was already using some non-default l10n.  But of 
course since I'm native en-US, in most cases I don't bother with l10n at 
all and don't even install the packages.  So for me, it'd probably be 
easier to simply find and patch the default pre-l10n string directly in 
the package code...  And one of the benefits of running gentoo is that 
once I find such a bit of code and deduce the change to it needed, I can 
create a patch and drop it in the appropriate location, and all updates 
get that patch from then on, as long as it applies (and when it no longer 
applies I get an error when that package tries to update, which I can 
investigate and redo the patch or choose another alternative as 
necessary).  And I do have a number of such patches so located in the 
appropriate location, thus being routinely and automatically applied as I 
update.

Tho they're normally for other things.  For instance, gwenview's default 
zoom-step was changed a number of versions ago to 100%.  But I preferred 
the earlier, much smaller increment, so I found the location where that 
was set and devised a patch that changed a "1." value to "0.05", and now 
have 5% increments once again. =:^)

AFAIK, the last time I actually had to do that with a name string or 
similar, was with (the non-kde) pan.  One release version was named (IIRC) 
"Der Geraet", which (with appropriate umlauts or whatever) I understand 
is German for "The Tool".  All fine, except that pan passes its version 
name as a message header, and RFC-standard internet-message headers 
aren't supposed to contain anything but 7-bit-ASCII (quite another 
problem, actually, requiring all sorts of encoding solutions and 
triggering various chicken and egg issues due to needing to know the 
encoding without having necessarily parsed the header that would declare 
said encoding, something that UTF-8 is gradually helping to solve, 
but...).  Anyway, I was and am running live-git pan, and with the commit 
changing the name to something now including non-ascii, I suddenly found 
my posts to various lists rejected.  But since I was running live-git, 
there were only a couple commits it could be, and the rejection-bounce 
from one of the lists mentioned it was a non-ASCII header issue, so that 
eliminated all but the one commit, making it easy to see what went wrong 
and to devise a patch without the umlauts or whatever non-ascii chars, 
which I then applied locally while reporting the issue upstream.  The 
first attempt at a fix simply attempted to encode the non-ascii, but that 
didn't work as the thing was decoded elsewhere in the code with the same 
non-ascii header as a result.  Of course that made my patch not apply.  
But there weren't that many other commits going in at the time, so while 
I continued updating to see when a further fix was applied, I simply 
didn't actually build a new version for a few days.  The second attempt 
at a fix basically applied the same patch I did, using the standard ascii 
text without umlauts, etc, at which case I was able to discard my patch 
and update as normal once again.

So that was only a few days' problem, but had I not been running live-git 
pan, it probably would have made it into a release, and been a much worse 
problem as it would have applied to many more people over a much longer 
period (probably a six-month distro update cycle at least, assuming the 
distro maintainer didn't catch it, as they probably wouldn't have given 
the nature of the problem).  But I /was/ running live-git, and the 
ability to apply patches like that allowed me to verify the problem 
before reporting the bug, as well as deal with it for the few days before 
a proper fix.  Which demonstrates the point, that this sort of problem is 
much rarer for FLOSS projects, since someone somewhere generally catches 
it and reports a bug back to the much more accessible authors, who 
generally fix it, and if not, the distros generally catch it in a cycle 
or two, so the problem goes away for most users, instead of persisting as 
it would with proprietaryware thru a much longer release cycle.

But in this case, apparently the "bug" has continued for some time, going 
to my point about kget being rather obscure for a FLOSS project, these 
days, so because it's not used much and some users wouldn't worry about 
such a trivial thing as a name or even <shudder> /like/ such MS-esque 
names, few people are reporting the bug, and those that are haven't 
caught the attention of the authors, so it remains unfixed.

-- 
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