[gentoo-amd64] Re: Re: Re: KDE - vanishing apps

[Duncan]

Guy Harrison posted <200602141959.23677.swampdog-ml6@××××××××.com>,
excerpted below,  on Tue, 14 Feb 2006 19:59:23 +0000:

> If I can trouble you with a further question, within kickerrc
> [Kmenu] where do I go next to find its entries?

The question doesn't quite parse as is, here, so I'm forced to make some
assumptions about what you meant.  If they are wrong, you will therefore
find the following likely doesn't answer your question, altho it might be
useful info in general.

First, a bit of general information about the organization of kickerrc and
its related "child" files.

Kicker deals with three basic types of components, buttons, applets, and
extensions.

A button is just that.  It appears as a button in kicker, and kicker
contains the code that handles the action taken when the button is pushed.

An applet is a dynamic application hosted by kicker.  Examples are the
clock and taskbar.  Often, these are stand-alone applications that have
mini-versions designed especially to run in kicker.  Examples are the
kdict applet, which puts a little text box in which you can enter words on
the kicker panel, which then pops up the main kdict application with the
results of the lookup, and ksysguard-applet, which allows graphs of
various system status elements (CPU activity, memory usage, network
activity, etc) to be displayed in kicker, just like the full standalone
ksysguard does, but with a bit more limitation due to the kicker display
format.  

An extension normally appears as an entirely separate panel.  Kicker by
default has one, called main, at the bottom of the screen, but you can
move it elsewhere if desired, and place additional extension panels
wherever you want them as well.  One of the extensions is a normal panel,
which, as with the main panel, can contain its own buttons and applets as
desired.  Other extensions are special purpose panels, including one
similar to the konqueror side bar, so it's always available even when
konqueror isn't running, another that's an icon based taskbar as its own
panel, etc.

The main kickerrc file contains information about the location of buttons
and applets running in the main panel, as well as information about the
location of the main and extension panels on the display, and what those
extension panels are.  For applets and extensions, the main kickerrc
normally refers to an additional "child" file, that contains the
configuration for that particular applet or extension.  Thus, if you are
running more than one clock (say you want a second one displaying the
time where a friend or relative is located, so you don't have to figure
out what time it is for him, manually), you'll have pointers to more than
one clock applet rc file, each of which contains the configuration for
that particular clock applet.  Likewise, each extension has its own config
file, which for panel extensions will contain information on their own
applets and buttons.

One particularly useful possibility of all this is to configure a second
panel, so you can have one set to autohide, for stuff that you want
available but don't want always taking up room on your display (perhaps
the kmenu and maybe the clock), and the other set to always-on-top, for
stuff you want visible at all times (perhaps the system status info of the
ksysguard applet, and the system tray, maybe the clock too).

So... if you see a setting in kickerrc that looks like a pointer to
another config file, it probably is.  Take a look and see if there's a
config file by that name with more config settings, if that's the
particular button/applet/extension you are investigating.

FWIW, the screenshot I posted a link to a few days ago may be be
interesting, if you wonder how I have mine set up.  I don't believe it
shows all my extension panels, and I'm running dual 21" monitors in
1600x1200 resolution each, so obviously, my configuration won't be
suitable at all for someone running a single 17" monitor in 1280x1024 or
even lower, but it should still be interesting to see what such a
power-user's screen looks  like, and to what use he's putting all those
pixels.  I had to take down the full size version, as I'm way over
bandwidth for the month (hopefully you can still reach the site, it was
still working as I posted this), but the two smaller 1/3 size 256-color
png and compressed jpg are still there.

http://members.cox.net/pu61ic.1inux.dunc4n/

Back to your question...  Unfortunately, the answer to where one finds the
menu layout for KDE isn't as simple as it used to be, and to be honest, I
can't give you as straight an answer here as I could a few years ago,
because of that. KDE is complying with the freedesktop.org menu standards,
which work one way, as well as providing backward compatibility with its
own older layout, which would have been quite familiar to anyone used to
the MSWormOS start menu, as it kept the menu in the same sort of tree,
located at /usr/share/applnk, I believe it was. Those work somewhat
differently. It's possible there's a third standard in there as well,
maybe backward compatibility with GNOME's pre-freedesktop.org layout, and
maybe others as well.

In addition to the above, there's the system locations, and user's own
locations, the configuration of which doesn't just add to the default
system location, but can delete (by hiding) or move default menus or
entries according to individual user preferences.

Finally, the fact that Gentoo slots its KDEs so more than one may be
installed at the same time, changes things.

I do have a rather customized layout myself, which is how I know what I
know about it, but to be honest, I'm not entirely up with the new
defaults, as I configured my layout some time ago and haven't had to
change it recently, as my old customizations just carried forward, so I
didn't have to worry about it.  

Note that with such a lot invested in customization, I'd be very upset if
I lost it.  Thus, when I upgrade KDE, I take the precaution of copying my
~/.kde* to a backup location.  Then I start KDE as my regular user and see
how it does.  If I don't like any changes made, I can compare the backup
config to the new one and see what changed, then change it back or merge
my customizations as appropriate.  However, I've very seldom actually lost
settings.  

What /does/ sometimes happen is that the upgraded KDE doesn't like
something about the old settings and won't run.  Then I have to kill X and
from a virtual console, usually running mc, I delete the broken config and
let KDE build a  new one from scratch.  That has always worked. Then back
out of X/KDE again, I'll delete the defaults, and copy over about half my
customized config.  They I restart KDE and see if it works. If it doesn't,
I know the problem is in the half I copied over, so try again with only
half  of that.  If it works, I know the problem is in the other half, so I
copy half of it over (so have about 3/4 now) and try again.  Eventually,
I'll isolate the issue to a single config file, after which I'll dive into
the file, likewise trying part of it at a time, until I find the section
that doesn't work.  Then I'll dive into that section, until I find the
line that's causing the problem.  By then, it's usually pretty obvious
what that section and line is configuring, and I can usually just take the
default and reconfigure it from the GUI to get the settings I want back
again.

What I'd suggest, and have used myself in other troubleshooting
situations, is a similar strategy.  Most of KDE's system settings are in
/usr/share, and nothing in that dir should be critical to system operation
itself, as the place for vital system config info is /etc.  Thus, it's
possible to find where a particular problem is by process of elimination,
making a backup of the dir, then deleting parts of it from the working
config, until you've found the effective part.  This is of course made
rather easier by common sense.  The docs dir for instance shouldn't have
any effect on configs, so you can leave it in place and not test it.

Similarly with your user configs.  KDE has a global ~/.kdeglobals, but
other than that, nearly all of its config is under ~/.kde*.  It's
therefore relatively easy to (from a virtual console) rename ~/.kde* to
*.bak, and test with a "clean" user config.  If that works as it usually
does, the simple if somewhat time consuming process of elimination
described above can be used to trace the problem location, pinpointing it
to any level of specificity, down to the individual line if necessary,
desired.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list