KDE 4.5.5: "Folder View" mode of desktop doesn't restore on login

Duncan 1i5t5.duncan at cox.net
Sat Jun 16 20:58:55 BST 2012 

Manuel Reimer posted on Sat, 16 Jun 2012 17:02:17 +0200 as excerpted:

> Duncan wrote:
>> If I'm reading you correctly, after a kde restart (logout/login), the
>> desktop stays in folder-view mode as shown in the settings dialog, but
>> it simply doesn't show any icons?
> 
> Exactly
> 
>> It sounds like what could be happening is that it keeps folderview, but
>> for some reason, isn't saving the folder it should be pointing at, so
>> when you restart kde, it's pointing at the wrong one, which either
>> doesn't exist or is empty.
> 
> Unfortunately, this doesn't seem to be the problem. I also killed ~/.kde
> completely and tried a new user.

Hmm... If it's happening with a new user and with the current user with a 
clean ~/.kde, then that clears your config as a problem.  That's where 
most such issues seem to appear.  It gets tough if that's not it.

> If I go to the configuration dialog, then it shows the correct path even
> after logout and login, but the icons don't show up...
> 
> I am not completely sure if I did something wrong when installing the
> system. Maybe I missed something. Slackware doesn't have dependency
> tracking...

Gentoo user here, so while I have dependency tracking, we're both 
somewhat independent thinkers not willing to settle for the most common 
solutions. =:^/

> My hope was, that there is some kind of "log file", which can be saved
> and posted here, so someone with better knowledge about the KDE
> internals may have a look at this. Is the ".xsession-errors" file useful
> for that? I get many stuff there after logging in, but nothing I can
> work with...

.xsession-errors... but kde devs apparently don't expect non-kde-dev 
users to be looking at the STDOUT/STDERR of graphical programs, so the 
output tends to be so incredibly noisy even on a normal install that it's 
all but useless for troubleshooting.  The exception is when someone has 
two installs, one working, one not, and can diff the output one against 
the other, thus filtering out most of the noise.

>> Or try the traditional...
>>
>> killall plasma-desktop
>>
>> ... which is what I tend to use instead of kquitapp.
>>
>>
>> After a few seconds, restart it...
>>
>> plasma-desktop
> 
> Will try that. Maybe this throws out some error message while
> restarting, which points me to the problem...

Yeah.  That's next.  Cutting the output down to only plasma should help 
some, tho I expect it'll still be noisy.


Further thoughts that may or may not help...

1) I don't actually know, does slack install kde as a handful of rather 
large, monolithic packages (kdelibs, kdebase, kdegames, kdegraphics, etc) 
as the sources have traditionally been shipped from kde, or does it split 
down to individual apps (kdebase split into all the packages necessary to 
start kde, kdegames split into the individual games and game-libs, etc)?

For a no-deps-tracking situation like slack, it would seem split packages 
would be a nightmare, tho they do make it far easier to cut out the bits 
of kde you don't use and only install what you use.

If you're doing the monolithics, then there's way less deps to screw up, 
and it's quite likely kde (or at least the features in question) wouldn't 
work at all if you got them wrong.

2) Following Anne's timing idea...  The implication has been that you're 
using a graphical login (a *DM, KDM or the like), thus starting X at 
boot, and only starting kde from there, with X already running.  What 
happens if you boot to a runlevel without that (or however you turn off 
the *DM on slack), login as your normal user at a the CLI, and start KDE 
from there, so KDE and X start together?

That's the way I've been starting X and kde for... probably a decade 
now.  I don't even have a *DM installed.  Back on Mandrake I used to do 
whichever, but at some point the *DM failed to work correctly, and I 
switched to CLI login and startx (with the XSESSION variable set to kde) 
exclusively.  I don't claim it's the magic answer, but it works for me.

The timings should be enough different between the two login and kde 
start methods that if it's a timing issue as Anne suspects, it might 
either work around the problem, or cause it to appear in a different 
form, thus hopefully giving us some hints...

3) Are you familiar with strace?  Basically, it sits between the program 
and the kernel, allowing you to trace the system calls made, etc.  I'm 
not a programmer so most of its possibilities don't help me much, but I 
HAVE occasionally found its file-access tracing useful indeed!  You'll 
also need a working knowledge of grep to do much with it, tho, as 
otherwise you have the noise aka needle in the haystack problem.

Expanding on the kill plasma-desktop and restart it idea above, try 
something like this from konsole after killing plasma-desktop:

strace -feopen plasma-desktop

Now that's going to spit out a VERY LONG (!!) list of every file plasma-
desktop tries to open so again we have the noise problem, but grep and 
etc can help bring it down to a manageable size.

We don't exactly know what we're looking for, but if Anne's right and 
it's a timing problem, then maybe it's a file access error.  Let's look 
for ENOENT (no entry, file doesn't exist) errors.

strace -feopen plasma-desktop 2>&1 | grep ENOENT

That's probably still too much, so let's limit it to /home

strace -feopen plasma-desktop 2>&1 | grep ENOENT | grep /home

Of course if you're not seeing anything there, maybe it's a missing 
library or something, you can reverse that to exclude /home

strace -feopen plasma-desktop 2>&1 | grep ENOENT | grep -v /home 

Of course you can similarly grep for /usr/lib, exclude (-v) ENOENT (what 
I normally do since I'm often looking for where the config files are), 
etc.


Other than that... at this point, about all I can suggest is trying 
something a bit newer.  kde 4.5 is nearly two years old, now (I'm 
actually behind as I'm still running 4.9-beta1 and beta2 is out), and a 
lot of fixes have gone in since then!  Of course as I believe I said in 
an earlier post, 4.5 was the last version to use hal, so updating beyond 
that's a bit complicated on an existing installation, but...

Hopefully, however, one of the above suggestions will provide some clues.

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

More information about the kde mailing list