Guy Harrison posted <[EMAIL PROTECTED]>, 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@gentoo.org mailing list
