Re: konqueror crashes when quitting
after bb's and Achim Bohnet's reply I feel a need to add some comments:
> where would be your problem to copy the .kde/share/apps/<application>
>-folder, und put it back after removing the .kde/ -folder?
Well, the problem would be exactly where it has been before in this case,
since it's been in .kde/share/apps/konqueror/bookmarks.xml ;-)
How do you think have I figured out where the problem came from? Do you really
think I had removed my .kde directory? Do you really think anyone would do
that (more than once...)? What I tried to express with my statement "removing
.kde fixes it" was that it was not related to a buggy installation whatsoever
but must have been related to something in ~./kde.
Sometimes it is *not* possible to find the problematic file in a reasonable
time. What then? Well, currently the only feasible way is to make a copy of
your ~/.kde directory, start KDE anew, and copy back as many configuration
files as necessary, until either your problem reoccurs or you have copied
back everything you need. Everything? Can you tell? No, at least I cannot.
So, what's the outcome? I for one have at least 3 ~/.kde-BACKUPorWHATEVER on
any machine I'm running KDE on, just in case that I've forgotten to copy
something back from there. (Yes, sure: By now I really could remove my .kde1
@both of you:
The real problem is that there are hundreds of files below ~/.kde that have
never seen any kind of user interaction. They are auto-generated once and
maybe never touched again. There are files that needed some work, like
bookmarks that take a long time to build up, and then there are socket files.
All of them turn out to be possible sources of trouble, but all of them are
mixed (in some ordered fashion) in one directory. Is this necessary? Is this
comfortable? I don't think so, at least as long as severe problems occur
within KDE that are related to some files in there.
It would be much easier to find the troublesome file(s) if autogenerated files
were separated from ones which required user interaction. It would be much
easier to recover your environment if *important* settings were separated
from say cosmetical, less important ones.