Pictures of Green and Red highlights in the KDE

[Duncan]

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.