Created attachment 879 [details]
Control Center on my test machine

I tried to install on my test machine Polish. I switched to the Polish and the classic icons and Control Center is displayed without problems.

Please try to switch to a different icons theme. And if different icons theme will be okay, so back to the classic icon.

(In reply to comment #1)
> Please try to switch to a different icons theme. And if different icons theme
> will be okay, so back to the classic icon.
Nope, this does not help. Note that icons are not the only problem - there is also no border around centre panel and no logo at the top.

I just checked on a clean profile and everything is fine. It seems that the problem is caused by configuration in ~. Any idea which part of the config could be causing this?

Just a hunch, in your old profile, before logging in, delete the ksycoca cache files:

$TDEHOME/cache-`uname -n`/ksycoca*

(Pre-R14, usually this is a sym link to /var/tmp/kdecache-$USER)

Another hunch. If you save sessions, then set your profile to start with an empty session:

KControl->KDE Components->Session Manager->On Login->Start with an empty session.

If your KControl is too difficult to read because of the problem, then before logging in, delete the files in $TDEHOME/share/config/session.

(In reply to comment #5)
> Another hunch. If you save sessions, then set your profile to start with an
> empty session:
> 
> KControl->KDE Components->Session Manager->On Login->Start with an empty
> session.
> 
> If your KControl is too difficult to read because of the problem, then before
> logging in, delete the files in $TDEHOME/share/config/session.
Nope, neither of your suggestions solves the problem.

Have you done any experimenting with R14? As you wrote that the problem disappears with a fresh profile, I wonder whether that happened along the way. If yes, then some profile config files were modified to accomodate certain R14 changes that are not compatible in 3.5.x.

Similarly, have you knowingly run either the migratekde3 or r14-xdg-update scripts?

I mention this because when we were first developing those two scripts, and when I was heavily testing the XDG conversions, the behavior you describe was common when trying to use the same profile between a 3.5.x and R14 environment.

Try the following:

grep -rn "X-TDE" $TDEHOME
grep -rn "share/applications/tde" $TDEHOME
grep "CommandURL=tde" $TDEHOME/share/config/khotkeysrc
grep "Application=tde" $TDEHOME/share/config/profilerc
grep "StorageId\[\$e\]=tde" $TDEHOME/share/config/kickerrc

If you receive positive hits then you have some R14 "contamination." Ignoring the fresh profile option, the solution will be to read the r14-xdg-update script and reverse the changes.

(In reply to comment #7)
> Have you done any experimenting with R14? 
No

> I wonder whether that happened along the way.
After upgrading from 3.5.13 to 3.5.13.1.

> Similarly, have you knowingly run either the migratekde3 or r14-xdg-update
> scripts?
No

Okay. Just looking for clues. :)

Did you try any of the grep commands I posted?

Do you have a screen grab of the broken akregator?

Created attachment 930 [details]
Broken Akregator

(In reply to comment #7)
> If you receive positive hits then you have some R14 "contamination." Ignoring
> the fresh profile option, the solution will be to read the r14-xdg-update
> script and reverse the changes.
Nope, I get no output from these commands.

Okay, that is good. Now we're pretty sure there is no R14 contamination.

Have you tried different languages other than Polish? How about the default English too?

(In reply to comment #13)
> Have you tried different languages other than Polish? How about the default
> English too?
Yes, it happens also when I switch to English.

Before logging into Trinity, try renaming the following (do only one at a time and in this order):

$TDEHOME/cache-`uname -n` -> $TDEHOME/cache-`uname -n`.bak

$TDEHOME/share/apps -> $TDEHOME/share/apps.bak

$TDEHOME/share/config -> $TDEHOME/share/config.bak

Renaming rather than deleting so as to preserve data that can be restored. :)

Bear in mind that if nothing changes we are nonetheless eliminating possible sources of corruption. If nothing changes then restore the original name and try the next step.

(In reply to comment #15)
> $TDEHOME/cache-`uname -n` -> $TDEHOME/cache-`uname -n`.bak
> 
> $TDEHOME/share/apps -> $TDEHOME/share/apps.bak
Neither of these two help.


> $TDEHOME/share/config -> $TDEHOME/share/config.bak
This works - both Control Center and Akregator display correctly. Nevertheless that's not a solution I would like to use - restoring all my configuration would be very tedious, so it would be good to pin the exact file responsible for the problem.

Not intended to be a solution, only a troubleshooting aid. :)

Okay, now we have narrowed the problem to config files.

First test: rename $TDEHOME/share/config/kcontrolrc and akregatorrc, then test those apps.

Second test: exit Trinity, rename $TDEHOME/share/config/kickerrc, then login. This will lose all of your kicker/panel settings, but we're only troubleshooting at this point. Hence renaming the files rather than deleting. :)

Repeat the second test with $TDEHOME/share/config/kwinrc.

Another suspect file is profilerc.

At this point we are looking for the proverbial needle in the haystack. We know the problem is confined to $TDEHOME/share/config. The game now is logout, rename a config file, login, test kcontrol/akregator. Repeat as necessary.

Once we discover the culprit file, we can evaulate possible long-term cures for all 3.5.13.1 users.

(In reply to comment #17)
I tried all files that you mentioned (one at a time) with no result. I noticed that profilerc seems unused - it was not recreated when I removed it.

The profilerc file is created/updated when making changes in KControl, often when changing file associations.

So those files made no difference. Start picking your way through the config files. Many are very app specific and can be ignored. I know this process will take time. :(

Eventually you'll find the culprit config file and then we can look into whether the problem is unique to you or something that needs attention for all users.

(In reply to comment #19)
> So those files made no difference. Start picking your way through the config
> files. Many are very app specific and can be ignored. I know this process will
> take time. :(
I will. The problem is that I have this machine at work, so I can't do it in my free time :/

Jan, try running the migratekde3 script. 3.5.13.1 does not include this script (3.5.13.2 probably will), but you can find the script in the GIT repository:

http://git.trinitydesktop.org/cgit/tdebase/tree/migratekde3

Save a backup of your profile ($HOME/.trinity), log out of your Trinity session, and run the script from a console.

Please check your profile kcontrolrc and akregatorrc for the following:

[HTML Settings]
AutoLoadImages=false

If the group and AutoLoadImages key is present, change the value to true. If the group is not present, create the group and AutoLoadImages key, set to true.

I can duplicate the original problem report by changing the respective values to false.

The default for AutoLoadImages is true. Deleting the key should restore the images to both kcontrolrc and akregator.

Be forewarned that setting AutoLoadImages=true in akregatorrc will download all images in each feed article. To disable images in the feed articles requires AutoLoadImages=false. Yet doing that disables images in the akregator welcome page too. That bug is noted in bug report 1360.

(In reply to comment #23)
> The default for AutoLoadImages is true. Deleting the key should restore the
> images to both kcontrolrc and akregator.
I had no such section in my kcontrolrc and akregatorrc files. After adding AutoLoadImages=true nothing changes :/ Should I try with the migration script?
 
> Be forewarned that setting AutoLoadImages=true in akregatorrc will download all
> images in each feed article. To disable images in the feed articles requires
> AutoLoadImages=false. Yet doing that disables images in the akregator welcome
> page too. That bug is noted in bug report 1360.
Well, in fact Akregator does not download images in the feeds (very annoying), but it didn't download them even when everything worked fine with panels (that is before update to 3.5.13.1)

Akregator inherits the HTML settings of konqueror unless overridden in akregatorrc. Before trying migratekde3, check your konqueror settings:

Settings->Configure Konqueror->Web Behavior->Automatically load images

Unbelievable. It turns out that panels were broken because I enabled AdBlock filters in Konqueror. If I turn off AdBlock filters everything works. I think I had filters enabled before the update.

(In reply to comment #26)
> Unbelievable. It turns out that panels were broken because I enabled AdBlock
> filters in Konqueror. If I turn off AdBlock filters everything works. I think I
> had filters enabled before the update.

On my second machine with KDE 3.5.10 + OpenSUSE 11.4 I have AdBlock filters enabled in Konqueror and everything works correct: panels are displayed as they should, images are displayed in Akregator.

Perhaps you could isolate which specific filter causes the problem? Split the filter list in half. If the blockage persists then split the remaining list in half again. If the problem disappears then the problematic filter is in the deleted filters. Split that list in half and continue the process until the problematic filter remains.

To correctly resolve this bug report we need to determine why the problem does not occur in 3.5.10.

Any progress with this report?

Sorry, I didn't have time to track this one down and I won't have access to the machine this problem originally appeared for the next 2 months, so I'm closing this report. If it ever happens again and I'll have the time to find the exact cause I'll post it here or on the list.

Okay, thanks. Bug reports can be reopened at any time. :-)