Sue Harris posted on Sat, 29 Aug 2009 07:10:15 -0700 as excerpted:
> No, I have not been doing any development. I am a novice user. I think
> this happened when the computer froze up once and had to be rebooted. It
> booted back up with the red and green menu highlights.
Looking at it closer, I'm now almost /sure/ you've somehow activated a
develper feature, as the green (as we already know) is the accelerator
keys (press that letter to activate that item when in that menu), and
with the closer look, I see the red is small letters that it thinks
should be caps, probably violating the HIG (human interface guidelines)
for whatever (KDE or Qt), and the yellow is potentially extraneous words
that it's suggesting the dev remove from the menu as unneeded.
>From your initial description, I only could figure out the green/
accelerator-key bit, and thought it might be some sort of accessibility
feature, but the other color-coded bits are definitely developer-only
worries, so it /has/ to be some sort of developer UI interface aid.
That's the only thing that makes sense at all.
As I said, I don't really know how to fix it, but, given that you say it
happened after a crash, what I believe happened is that you got a bit of
file corruption due to the crash, and whatever config file it's pulling
that from, probably has a bunch of junk from another (possibly previously
deleted) file in it. At least part of the junk happens to make sense to
the system as it's trying to interpret the config, and is turning on this
feature as a result. =:^O
Anne, could you mail or IRC one of the KDE UI devs, providing them the
imagebin links, and ask them where that configuration file happens to
be? Note that the menus say kde3, so it's not current, but someone
surely knows. It's /gotta/ be a dev feature, no other explanation makes
sense.
Meanwhile, Sue, first thing, if it didn't run one when you rebooted that
time, try running a full fsck on at least the partitions holding your
home directory and /usr/share (presuming that's where ArkLinux puts the
kde system config). If you don't know how, consider asking on the
ArkLinux lists/forums/whatever, if they have them. Or, let us know what
filesystem type (ext3, reiserfs, whatever) you are running, and someone
can probably help you with it here. There might be other damage getting
worse, that an fsck should stop.
After you know your filesystems are in order and after a reboot (it's
often simplest just to reboot after an fsck, tho people who know what
they are doing can normally avoid it), then it's time to see if we can
fix the problem. You can either wait and see if Anne comes back with a
specific file and possibly line or section in the file to edit/delete, or
try what's called the bisect method, trial and error testing half your
config, then if it works you know the problem's in the other half, and if
it doesn't, you know it's in the half you tested, then taking half of the
half you know is bad and try it, splitting the testing domain in half
each time until you arrive at a specific file, then either delete it, or
edit it, until you arrive at a specific section, then line, of the file
(assuming a text based config file, which it almost certainly is).
If you choose the bisect method, from something OTHER than KDE, so from a
console text login or from Gnome or the like, RENAME your kde config dir,
probably ~/.kde or ~/.kde3 or the like, depending on how your
distribution arranged things. (I'll use ~/.kde in the examples going
forward, change it as appropriate if necessary. ~ indicates your
homedir, of course, and the leading dot in the filename indicates a
normally hidden file or directory, you'll need to turn on view hidden
files in whatever file manager you're using or use ls -a at the command
prompt, to see them.) Try naming it something like .kdetest.
Then log back into kde. Note that without its config dir, almost
everything will be set back to the defaults. That's the idea in this
case, but we're just testing, we'll fix it, later.
See if the problem has disappeared along with the default configuration.
If it has, we've just confirmed it's in your user kde configuration. If
not, then it's elsewhere.
We'll assume it's in your kde config for now, and that the rename so you
started with defaults fixed it. Reply and we'll try something different
if it didn't.
Quit kde again and again from outside it, delete the new, now mostly
defaults, config dir kde created. Rename/move the old one back into its
place. (Given the above assumption, .kdetest renames to .kde again.)
Now, as I'm assuming we just confirmed it's inside ~/.kde, I can explain
that there are two primary configuration locations in it, both in its
share subdir, ~/.kde/share/config and ~/.kde/share/apps. Still with kde
not running, rename choose one to rename, say apps, to ~/.kde/share/
appstest (thus leaving config as it is).
Log back into kde, and see if the problem is there or not. If it is, you
now know the problem is the remaining one (config, since we renamed
apps). If it's not, you know it's the one you moved (apps).
Quit kde again, and rename the tested dir back to its original again.
Depending on the results above, switch to whichever dir (apps or config)
was the problem.
If the problem was the config dir, it's mostly files; if it was apps,
it's subdirs for each app.
Do the same thing here, only since there's so many, you don't want to
rename them all, so create a new subdir called test, and move half the
files or directories into test, leaving the other half.
Login to kde again, and repeat, narrowing it down further...
At some point, you'll have narrowed it down to a single file. You now
get to use your judgment. If you don't customize that much or at least
didn't customize whatever's in that file that much, you may wish to
simply delete it, and recustomize whatever config you lost in doing so.
The alternative is to continue narrowing the problem down, to a single
section, then a single line, in this config file, only now using a text
editor instead of file and directory movement to split the config down to
an individual line, if you choose to go that far. Of course, then you'll
probably delete that line, tho it's possible you'll edit it to some other
value instead, if you know what it's supposed to be based on reason.
If you choose to go the bisect route, please do let me know where you
found the issue, as I'm seriously curious, at this point. Of course, if
Anne comes back with an answer on what file to look in and perhaps what
line, that'll be my answer, but a confirmation that it worked would still
be very useful, in case someone else ends up with the problem at some
point, and to satisfy my curiosity, of course. =:^)
Of course if it turns out that renaming the .kde dir does nothing, let me
know that too. There's a couple of general kde config files that aren't
in that dir, and it could be a qt feature not a kde feature directly, as
well, in which case it'd be in the qt configuration. But we'll deal with
that if it happens. I'm hoping it's in the .kde dir.
--
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 mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
