<SNIP>
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.
That is the problem, I have a local configuration file and it has not
disappeared. My analysis is that there is no way for it to know when to
disappear.
What should have happened is that when I added another KGet group that a
local configuration file containing: "My Documents" was created. That
worked. At that point, it should have become possible to rename or
remove: "My Documents". But, that fails. So, I removed it by hand and
that made no difference. This is the bug. This is complicated by the
fact that it is not possible to click the: "Apply" button after making
changes here, so the new file is not immediately written. This appears
to be another bug.
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.
And, when a user does configuration, it should become editable. And,
even reappear if the user removed all KGet groups.
I also find it strange that the default group has no default file name
-- "*" would be recommended rather than: "'movies'". Which would be a
third bug.
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",
And there appears to be an odd interpretation of that with people that
call themselves 'developers' getting upset when people fix bugs for
them. Now, if they wanted to have a discussion about how to best fix
the code or even about the relative merits of when to use a: "goto" in
C/C++, I have no problem with that.
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.
I guess that I subscribe the what I have always called the Vulcan
philosophy here since I can't remember the correct philosophy that it
actually belongs to. My logical proposition is that there actually are
objective standards of how things should work. The question then is
whether there is one objective BEST way to do something. I think not
but there ARE ways of doing it that are objectively the wrong way to do
it. This leads to the conclusion that some things just don't work right.
There is also a corollary for KDE (and probably other desktops) that
there is a way that the desktop does things that should be followed if
possible.
Example: The digital clock format should _start_ with what has been
selected in the: "Locale" KCM.
If you recall, the bug in question was that KDESU didn't work. And, I
was willing to take the code from the patch on my system and merge it
with another problem that someone was having. All that was necessary
was to leave me alone from the time I reopened MY bug (that I filed) --
doing which was a proper thing to do according to what I had read since
the minor release (middle number) had been incremented and it still
wasn't fixed (not to mention that it had been falsely closed as a
duplicate). But, no someone felt the need to harass me. Just as a user,
I figure that if it isn't fixed and nothing is being done that I have a
right to reopen a closed but unfixed bug that makes it impossible for me
to use KDESU (except that I patched my system).
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,
Not a good end for the users if bug reports are ignored because I filed
them.
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.
Yes, my system has patches.
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.)
C/C++ is not my language of choice. Naturally, I think that PL/Fiv (the
language which I designed) is better, but all I have is a partially
finished compiler that runs on PC/DOS. I suppose that a front end for
GCC would be possible but it would discard one of the design objectives
which was to eliminate a large chunk of the compilation process.
I could probably just use The F Programing language, but there are no
KDE bindings for it. Someone that totally didn't get it thought that I
could simply work from the existing bindings. Didn't seem to notice
that all of the existing KDE bindings are for interpreted languages.
For some reason, Java isn't really available (a one way street with JNI
is what it is). I would think that that would be simple but perhaps
not. GCJ will compile Java into native machine code as well as byte
code. You can add Java to a C++ program with GCJ, but not the other way
round. So, you can add Java classes to a KDE program, but the KDE
interface remains in C++ -- you still have a C++ main program. IAC, it
has vanished.
I still use an online reference and make stupid mistakes. However, that
isn't the point. I was very good at programing which is, IMHO,
independent of the language being used. The problem with C/C++ is
writing code, not designing what it should do -- probably the opposite
of self taught hackers.
<SNIP>
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! =:^)
I will have to give it another try -- the first try did not find it in KGet.
--
James Tyrer
Linux (mostly) From Scratch
___________________________________________________
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.
