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.
