[kde-linux] Unpopulated Control-Center window

[Stan Goodman]

At 02:45:04 on Tuesday Tuesday 01 December 2009, Duncan 
<1i5t5.duncan at cox.net> wrote:
> Stan Goodman posted on Mon, 30 Nov 2009 21:40:53 +0200 as excerpted:
> > At 18:31:11 on Monday Monday 30 November 2009, Werner Joss
> >
> > <werner at hoernerfranzracing.de> wrote:
> >> Am Monday 30 November 2009 17:21:27 schrieb Stan Goodman:
> >> > I'd be grateful for advice on how to restore this functionality.
> >>
> >> maybe running kbuildsycoca --global helps (kbuildsycoca4 for kde4) -
> >> this should rebuild the control center database/cache.
> >
> > This is what happened:
> >
> > # kbuildsycoca --global
> > Warning: kbuildkbuildsycoca is unable to register with DCOP
>
> "kdesycoca" is I believe short for "kde system config cache" (kde, plus
> the first two letters of each word thereafter).  Unlike, for example,
> MSWormOS, KDE doesn't have a binary blob registry, but rather, chose
> the *nix way of configuration, text based configuration files -- rather
> a lot of them for something as big as kde.  But accessing and parsing
> all these text files is slow, so the data is saved into the "kdesycoca"
> (again, system config cache) binary cache, and under normal conditions,
> applications simply use the data as it's found, there.
>
> It then becomes kbuildsycoca's job to update the kdesycoca database
> when anything besides kde touches it.  (When kde apps change their own
> config, the system updates both the text file and the running
> dcop/dbus. kbuildsycoca is designed to bring in changes made thru
> non-kde means, editing the config files directly with a text editor,
> for instance, or when the package manager installs or uninstalls
> something.)  When kde starts, kbuildsycoca normally runs automatically
> in incremental mode, doing a quick check to see what config files if
> any have changed and updating that part of the config cache.  However,
> sometimes that doesn't catch all the changes.  If from a terminal
> (konsole window or CLI login) you run kbuildsycoca (kbuildsycoca4 for
> kde4) --help, you'll get a list of command line options, including the
> --global and --noincremental options we're interested in here. 
> --noincremental forces a reread of all text files, regardless of
> whether they'd be detected as changed or not. --global creates the
> global database from scratch.  (FWIW, I'm not sure what the difference
> between them might be.  Perhaps --noincremental only checks files known
> to exist while --global checks all known locations for new files, as
> well?)
>
> > That sounds like the reason the problem exists in the first place.
>
> dcop for kde3, now a common dbus, used by both kde4 and gnome, is the
> system message bus -- the way dcop/dbus enabled apps talk to each
> other. If there's something wrong with things as there is if you don't
> see a populated kcontrol, dcop may indeed not be running.  It seems
> particularly sensitive to kdesycoca corruption, and it's not unusual at
> all to have it crash (silently, you only know it happened when stuff
> starts acting weird) as a result.
>
> kbuildsycoca (I expect that second "kbuild", as in kbuildkbuildsycoca,
> above, is a typo) will in my experience then need to be run twice, the
> first time with the mentioned error but fixing things up at least
> enough to run dcop, the second time succeeding, ensuring that any loose
> ends are fixed up as well.
>
> Now there are some "interesting" (as in that old said to be Chinese
> curse, may you live in "interesting" times) problems when kde3 and kde4
> are installed on the same box, especially when you try to run apps from
> one in the other.  Depending on the setup (generally, depending on
> whether the distribution has set it up so both can run together or not,
> and whether the sysadmin has perhaps changed some settings, possibly
> long before kde4 ever entered the picture, such that the distribution's
> working cohabitation config breaks), both the kdesycocas might be
> fighting each other, trying to use the same cache file, each in turn
> overwriting the other, depending on whether a kde3 or kde4 app was run
> last.  I had this problem for awhile, so I know how frustrating it can
> be.  But while that's the most obvious problem, other more complex
> problems exist as well.  Again depending on the setup, the kde3 and
> kde4 apps may be overwriting each others text configs, thus corrupting
> the data used to generate the kdesycoca in the first place.  If that's
> happening, it's possible kbuildsycoca won't be able to make sense of
> things at all, and there'll be no way to get a sensible config.  In
> this case, checking the sysadmin's (or user's) own settings to see if
> for example, the KDEDIR or KDESYCOCA environmental variables are being
> set and exported, thus thwarting the distribution's efforts to keep
> things separate, might help.  If neither the user nor the sysadmin on
> the local system has changed such settings, perhaps the distribution
> isn't setup to allow both kde3 and kde4 in parallel.  In that case, the
> old
> recommendation from the kde4 developer docs might help: run only kde3
> OR kde4 apps as a single user.  Use a separate user to run apps from
> the other version.
>
> FWIW, the problems I had here were a combination of my own settings
> fighting the distribution settings, and the distribution not getting it
> quite right for some time.  Once someone from the distribution's kde
> project blogged that they thought they had it worked out, and to check
> the individual system and user settings and NOT set specific variables
> like the two mentioned above, and I unset the ones I had been setting,
> everything in that regard "just worked".  In fact, it worked so well
> that I was able to switch to kde4 incrementally, an application at a
> time, by uninstalling the kde3 app so the kde4 app would be used, while
> still in kde3, setting up that kde4 app as I wanted it, then moving on
> to the next one.  So that's what I did with konqueror, konsole, kmail,
> etc.  Then for kwin, I killed the kde3 kwin and started the kde4 kwin,
> configuring it using kcontrol4 (generically aka system settings, altho
> it's kde4 settings it controls, NOT general system settings!).  Once
> /that/ was done, the only critical thing left was plasma itself.  I
> quit kde3 and started kde4 at that point, and configured plasma-desktop
> from there.
>
> Obviously, that would not have worked, had the kde3 and kde4 stuff
> still been fighting each other, so the distribution did a pretty good
> job of getting them working together... once I got the kde3-only era
> vars I had set out of the way. =:^)  FWIW, I was eventually able to
> uninstall kde3 and qt3 entirely, tho it took awhile to find
> replacements for the kde3 functionality (such as global multikey
> khotkeys) that remains broken in kde4, in that case, apparently
> permanently, according to the bug.
>
> Meanwhile, there's another area the problem could be in, as well.  I
> left this for last as I don't remember the details for kde3, but
> perhaps it can at least point you in the right direction, if you get
> this far without a fix.  In general, the desktop file entries that tell
> kcontrol3 what menu items (for that's what they are) to include in
> kcontrol are like any other kmenu desktop file entries... but for two
> changes.  One, the kcontrol entries are hidden by default, and thus do
> NOT display on the menu as they would otherwise.  IIRC this is
> accomplished with a HIDDEN=true entry in the file, or some such.  That
> explains why they aren't normally on the menu, even tho they're mostly
> ordinary menu entries.  Two, I think they have a kcontrol=true or
> similar entry (I think that one's something different, but if you find
> the associated desktop files, you should recognized the line) of some
> kind, as well. This is what actually tells kcontrol that it should
> appear in it. Without that, it wouldn't appear in kcontrol.
>
> Finally, there's one other change in this area, with two parts.
> Somewhere, I think it's an environmental var but don't recall exactly,
> there's a setting that tells kcontrol which submenu of the kmenu to
> look in to find its control modules.  There's a default, to .hidden I
> think (with the whole submenu hidden, again with a desktop file entry,
> HIDDEN=true or some such), if the variable (or whatever) isn't set, but
> regardless of whether it's using the default or is pointed elsewhere,
> if that submenu doesn't exist or does but isn't what that setting is
> pointed at, all the desktop file entries for all the kcontrol applets
> may be setup perfectly fine elsewhere in the kmenu, but kmenu will
> still appear empty, because it's pointed at the wrong place to look for
> them.
>
> I actually had this happen to me at one point as well.  Thus, I
> remember it, but it was some time ago and since I only have kde4
> installed now, it's not like I can verify the details too easily.  But
> maybe there's enough there to at least point you in the right
> direction, and by looking around on your system and googling, you can
> find the rest.
>
> > I should also mention that upon boot, there is a dialog box, as
> > follows:
> >
> > *****
> > x console <2>
> > smartd[2004]: Device: /dev/sda [SAT], 2 offline uncorrectable sectors
> > Console log
> > *****
> >
> > This seems to mean that I have two bad sectors in the area of the HD
> > used by this OS. I suppose this may be what is behind the
> > non-functional kcontrol.
>
> If they're detected and offline, then reinstalling whatever was on them
> should fix the problem, since they're now marked as bad.  So try that
> if you need to.  But I suspect the problem has been there for awhile
> and isn't the problem in this case.  Unless it just started showing
> that, and/or you see the uncorrectable sector numbers start increasing!
>  If they start increasing rather regularly, you better make sure your
> backups are up2date and tested to work, or absent that, shut things
> down and get a new disk *NOW*, praying that the old one survives long
> enough to get the data you need off of it transferred to the new one.

Thanks to both you and Jim for the explanation and suggestions.

Loss of data for this installation is unimportant, because there isn't 
any. This is openSuSE v11.2, which is newly installed on an area of the 
HD which was previously not used.  Also present on the HD is an 
installation of oS v11.1, which is backed up. The machine is a new 
laptop, still in warranty.

My conclusion from your detailed explanation above is that trying to 
retain KDE3 on an OS that wants to install only KDE4 is more trouble than 
it is worth. When I reinstall the oS v11.2, it will almost surely be with 
GNOME; I do not like KDE4, which is anyway unusable for me because 
the "new and better" text module has a serious flaw with right-to-left 
languages (Hebrew and Arabic). No doubt KDE will get around to fixing it, 
but meantime I wouldn't have a usable system. But I confess that I didn't 
like KDE4 before I discovered this, and I regard having been pushed into 
KDE4 as a diktat of a kind which I would have attributed only to 
Microsoft.

-- 
Stan Goodman
Qiryat Tiv'on
Israel