KDE4 Control Center confusing

[Duncan]

genericmaillists posted on Sat, 31 Oct 2009 01:48:48 -0400 as excerpted:

> No, I could not get it to save anything other then probably the
> container, which did nothing. It would not save the configuration inside
> the option at all. Even doing a re-boot and trying again got the same
> results, the error.

Hmm... Do you have strace installed?  Do you know how to use it?  If not, 
you can take a look at the manpage, but I'll often use it to find what 
files a program is accessing or trying to access.  It prints a ***LOT*** 
of output by default, probably thousands of lines for even a typical 
short and simple startup and shutdown and app, without actually doing 
anything, so one ***MUST*** learn how to filter the output, but once 
that's learned, and with a bit of patience, strace can reveal all sorts 
of stuff.

Of course, so could reading the source... if one's skilled enough in the 
art to actually understand what one's reading, but for many of us, 
learning to filter the strace output for a run is easier than poring thru 
source not really knowing what one is looking at, for hours, hoping the 
needle in the haystack will shine enough to pickout when we finally get 
to it.

Anyway, to see what files a program is opening, 

strace -eopen <program> <program's command-line parms>

Of course, run that in a konsole or other terminal window.

-eopen says to only report on system calls that attempt to open files.  
Depending on the app and how it works, one might also need the -f, follow-
forks-also, option.

However, a typical X program will still spit out hundreds of lines of 
attempted file-opens, icons, fonts, config-files, X-sockets, cursors, 
multiple shared system libraries, all sorts of stuff, many items of which 
it'll actually check several locations for by default, until it finds 
where the file is actually located on your distribution.  One thing 
working with strace does is give you an *ENTIRELY* new appreciation for 
just how much work your computer does when it runs a program, and a new 
awe that it can actually do all that in the short time it normally 
takes.  Once one sees the output, it's not hard to imagine it taking 
hours to start a single program, but it does it in seconds, often 
fractions of a second if all the files are in-cache.

Anyway, the result is that even filtering to only file-opens is way too 
much haystack to sift thru.  That's where the pipe to grep comes in 
handy.  If you know the approximate location of the file access you're 
looking for, you can grep for it.  If not, then you grep -v (only show 
lines NOT containing the grepped string), filtering out all the common 
stuff, one thing at a time.  So a line such as this isn't unusual, when 
looking for a config file access:

strace -feopen <command and parms> 2>&1 | grep -v 'icon\|cursor\|lib\|
font'

That'd get you started.  The 2>&1 redirects STDERR to STDOUT so it can be 
grepped, as strace outputs to STDERR.  You'd probably add more cases to 
that regex OR expression as you found them.

In our case, however, the config files we're looking for are going to be 
in one of two locations, either under /usr/share/ (assuming that's your 
kde system configdir) or under ~/.kde/share/ (assuming that's your kde 
user configdir).  Thus, something simpler, like this, is a good way to 
start:

strace -feopen kcmshell4 solid-actions 2>&1 | grep '/share/'

(kcmshell4 is what's used to launch individual kcontrol applets.  You can 
get a list using kcmshell4 --list.  There really are some interesting 
ones!  A quick kcmshell4 --list | grep device gave me several 
alternatives, solid-actions looked the most likely, and running it 
confirmed it.  We're using that here, to shorten the strace output that 
would otherwise show up as it loaded the various things as you searched 
for the device actions applet.)

Even with that filter, it gives me ~150 lines of output, here, but that's 
at least a bit digestible, and you can run that into a second grep -v to 
filter out irrelevant stuff (probably /locale/\|X11...) if you want.  Or 
if you aren't interested in the system config in /usr/share, only your 
user config, change the grep /share/ to your home share dir, eliminating 
all the /usr/share entries in one whack.

The object of all this is to find what config files it's actually writing 
-- or attempting to write -- to.  You can then check permissions 
appropriately, maybe open them with a text editor and see if the format's 
simple enough to manually configure doing a text-file edit, etc.  Of 
course, as I said, you can check the sources if you know how to read 
them, but I was using this technique back on MS Windows (using a file 
access reporting tool other than strace, of course) over a decade ago 
(It's been nearly that long since I switched to Linux and freedomware) 
for proprietary apps, and it works just as well on Linux for freedomware 
apps.  It really does work amazingly well; one just needs a bit of 
patience as one figures out what grep regexs to use to cut the haystack 
down to something manageable in which one can hope to find the needle 
one's looking for! =:^)  If I were really efficient, I'd setup a script 
with all the normal filters (icons, fonts, etc) already included, so I 
could just run the script, feeding it the app and parameters, and 
filtering output further as necessary, but I haven't, yet.

-- 
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.