Re: [kde] How to learn about all those configuration file values?
Adrelanos,
adrelanos wrote, On 04/02/2013 04:10 PM:
> There is an Ubuntu Package kde-settings-lowfat. The creator of that
...
> At the bottom is a list of settings I can hardly make head of tail of. I
> am not asking to tell me what each any any values do, I am just asking
> about the best approach to learn all those things.
...
> didn't help. I assumed to phrase a configuration file which contains
> "[Module-kwrited]" you must somewhere use the word "kwrited" in the
> sources and at least by reading the source I should get an idea what it
> does, but I also don't find references for it in "kwrited", so I am
> really lost on how to find reliable information.
I think we all are. Unfortunately, useful documentation seems to
get sparser and sparser in the brave new world we live in.
> Please tell me how I can find best information about these settings.
>
> Cheers,
> adrelanos
I'm going to spew some stuff that is probably 90+% true, and may not
necessarily be the best way to determine this stuff, but hopefully
is at least useful.
> /kde/share/config/kdedrc
>
> [Module-bluedevil]
> autoload=false
...
kded is the "KDE Daemon",
http://api.kde.org/4.0-api/kdelibs-apidocs/kded/html/index.html
each of these "Module-*" group identifiers represent a service
adjunct daemon that 'kded' is responsible for starting. In the
cases you reference, the 'autoload' key is being set to "false",
indicating that 'kded' won't start those auxiliary processes.
(presumably to reduce startup times, memory consumption, additional
opportunities for bugs to bork your session...)
You can get *some* idea of what the currently loaded kded modules
do by this dbus call loop:
# figure out where the KDE4 system services directory *probably* is
d=$(kde4-config --path services); d=${d##*:};
** i reference value of '${d}' in other examples below...
# get each loadedModule from 'kded'
for module in $(qdbus org.kde.kded /kded loadedModules)
#look in the associate service .desktop for a comment
do printf "%32s - %s\n" "$module" "$(grep '^Comment='
${d}/kded/${module}.desktop | sed -e 's/^Comment=//')"
done
e.g.:
networkstatus - Tracks status of network interfaces and
provides notification to applications using the network.
remotedirnotify - Provides change notification for network
folders
soliduiserver - Provides a user interface for hardware events
powerdevil - Battery, Display and CPU power management
and notification
or get them all with:
for dt in ${d}/kded/*.desktop; do \
printf "%32s - %s\n" "$(basename "${dt}" .desktop)" \
"$(sed -ne '/^Comment=/{s/^Comment=//;p}' "${dt}")"; done
or, 'man kded4' seems to have much of this as well.
As for the 'krunnerrc' [Plugins] group, same sort of deal:
> /kde/share/config/krunnerrc
>
> [Plugins]
> PowerDevilEnabled=false
> bookmarksEnabled=false
...
> windowsEnabled=false
services files with "X-KDE-ServiceTypes=Plasma/Runner" are the
plugins listed above.
The configuration key: "X-KDE-PluginInfo-EnabledByDefault" defines if that
plugin
is enabled or not.
$ for dt in $(grep -l X-KDE-ServiceTypes=Plasma/Runner $d/*.desktop); do
t=$(basename ${dt} .desktop); printf "%32s - %s\n" "${t}" "$(sed -ne
'/^Comment=/{s/^Comment=//;p}' $dt)"; done
browserhistory - Searches in Konqueror's history
CharacterRunner - Creates special characters from their
hexadecimal codes
katesessions - Matches Kate Sessions
konquerorsessions - Matches Konqueror Sessions
...
plasma-runner-windowedwidgets - Find Plasma widgets that can be run as
standalone windows
plasma-runner-windows - List windows and desktops and switch them
recentdocuments -
In general, google searching for
"KConfig "
"kcfgfile "
might get you something useful.
Another thing i often have to do is :
$ rsync -axWS ~/.kde/ /var/tmp/${USER}-kde/
run a kcmshell4 / system-settings UI and toggle or change something,
then:
$ kompare ~/.kde/ /var/tmp/${USER}-kde/
(or diff -hwbr ~/.kde/ /var/tmp/${USER}-kde/ )
to figure out what KConfig key values changed in the process.
unfortunately, the converse (change a value and dig through UI
screens is MUCH more work ;}
btw, you can generally put SYSTEM LEVEL overrides in /etc/kde4/...
$ cat /etc/kde4/nepomukserverrc
[Basic Settings]
Start Nepomuk=false
overrides the Start setting for nepomuk.
Good luck.
--stephen
___
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.
[kde] Running kde 4.10-live-branch now Was: Yet another failed KDE release?
Duncan posted on Sat, 23 Mar 2013 11:40:30 + as excerpted: > [dE wrote... snipped] > While I'm not ready for trunk-live, I already run the pre-releases, and > have seriously considered switching to branch-live. However, while I > have git installed and most of kde has switched to git, I don't have svn > installed, and a few packages (less every release) remain on svn. And I > remember the svn deps as rather more complex than I really want to deal > with, so I decided not to switch to kde-branch-live until the bits of > kde I actually install, mainly core-desktop, with much of the artwork > and many of the games, was all on git. Last I looked, mid-4.9 (before > the 4.10 pre-releases hit IIRC) some of my installed kde packages were > still svn based, so I didn't switch. But with 4.10 I think some > switched, and I believe others are switching for 4.11, so I'll probably > investigate again and I may well switch to the 4.11.49. live-branch > builds when they come out. Actually, I decided to check before I did the 4.10.2 upgrade, and found I could upgrade to 4.10-live-branch (aka 4.10.49. for gentooers) with a handful of unmerges (most of the kdeartwork module), and commenting the ** keywording of oxygen-icons in the 4.10.49. package.keyword file from the gentoo/kde overlay. All the other kde-base packages I have merged are switched to git upstreams, but the artwork stuff is still in svn, probably because git isn't particularly efficient with binaries so the switch isn't a big deal for the kdeartwork team. So but for oxygen-icons, I'm now running 4.10.49.. =:^) Some package stats: * I have 143 kde-base packages merged, of which 142 (all but oxygen- icons) are now live-branch 4.10, with oxygen-icons upgraded to 4.10.2 in the process. * I have 144 packages in my @live-rebuild set, the 142 kde-base packages, plus a couple others (pan, my news client, and openrc, gentoo's default init system). * With ccache active and caching my rebuilds, fresh from the kde upgrade so with a hot ccache and a hot file cache in memory, a timed full @live- rebuild of all 144 packages took under half an hour (just over 23 minutes), averaging a load of 2.7. That's on a 6-core amd bulldozer fx6100 @ 3.6 GHz running the kernel's conservative PM governor, with a "spinning rust" hard drive bottlenecking things part of the time, but with the portage tmpdir on tmpfs and 16 gigs memory, with portage's parallel make active at --jobs=12 --load-average=12 and MAKEOPTS="-j20 -l15". I was running my normal X/kde session at the time and doing the build from a konsole session, with an incoming shoutcast stream playing and my usual once-per-second superkaramba performance graphing going on, so the system wasn't idle but was being only relatively lightly used during the timed rebuild. * Based on the above hot-cache 23-minute time, I figure if I do the @live-rebuild with my normal system updates 1-4 times/week, the kde updates should still take under an hour, so maybe 1-1.5 hours for the full tree and overlays sync, normal --update --deep --newuse @world, and @live-rebuild. Since the process is well automated and I can continue using the computer for catching up on news, lists, etc, while it's building, actual interactive management time should be minimally incremental, less than a half hour a week, I'd guess. Of course as has always been the case, the big management time cost will be every six months or so, with the bump to the next kde feature series and the package shuffle, etc, that goes along with that... I don't think I'll try trunk-live in general, tho it's likely I'll try it temporarily, between the beta-1 release and the branch splitoff, thus getting the beta-period fixes "hot out of the repo" instead of having to wait for the next pre-release, as I had been doing, while avoiding the longer commit-window during which trunk is far more in flux. I guess I'll know how it's going with live-branch in a few weeks. 4.11- beta1 is scheduled for mid June, so I imagine I'll be switching to trunk- live about that point, and you can ask me in early July how that's going... -- 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.
