KDE4 Control Center confusing

[genericmaillists]

The control center in KDE4 is confusing and limited compared to KDE3.5.

Setting up device PNP actions was relatively straight forward and easy to figure out in KDE3.5 but that does not seem to be so in KDE4.

When I put a movie DVD in the CD/DVD-ROM drive I get five available actions. One of those actions is Open with File Manager.
When I put a music CD in the CD/DVD-ROM drive I get three available actions. The Open with File Manager or Play with Amarok is not in the list to choose.

Looking in the control center under device actions left me stumped trying to figure out how to change that so I can choose Open with File Manager.

Clicking on Help did not make it clear either.

Is there any documentation available that does explain this so a person new (not new to KDE or Linux) to the KDE4 environment can learn how to do this?

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

[Anne Wilson-5]

On Friday 30 October 2009 02:02:49 genericmaillists@... wrote:
> The control center in KDE4 is confusing

Some say so, and it is currently being redesigned.

> and limited compared to KDE3.5.
>
I don't believe so.  Of course some configurations have been moved to be
configured within the applications that are affected.  Otherwise, I haven't
noticed anything missing.

> Setting up device PNP actions was relatively straight forward and easy to
> figure out in KDE3.5 but that does not seem to be so in KDE4.
>
> When I put a movie DVD in the CD/DVD-ROM drive I get five available
>  actions. One of those actions is Open with File Manager.
> When I put a music CD in the CD/DVD-ROM drive I get three available
>  actions. The Open with File Manager or Play with Amarok is not in the list
>  to choose.
>
> Looking in the control center under device actions left me stumped trying
>  to figure out how to change that so I can choose Open with File Manager.
>
> Clicking on Help did not make it clear either.
>
> Is there any documentation available that does explain this so a person new
> (not new to KDE or Linux) to the KDE4 environment can learn how to do this?
>

Basically it is exactly the same as in KDE 3.x.  The context list is affected

by your choices in File Associations.  In 3.x you could add to the list with a
context menu, IIRC, but the main way was always in the Control Centre, File
Associations section.  In KDE4 it's in SystemSettings > Advanced tab > File
Associations.  Add to the list any applications that you want to associate
with the file type, remembering that the top one in the list will be the
default - again, exactly as it was in KDE 3.

Anne
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature?  Add it to UserBase


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

[Duncan-2]

Anne Wilson posted on Fri, 30 Oct 2009 12:10:28 +0000 as excerpted:

>> Looking in the control center under device actions left me stumped
>> trying to figure out how to change that so I can choose Open with File
>> Manager.
>>
> Basically it is exactly the same as in KDE 3.x.  The context list is
> affected by your choices in File Associations.  In 3.x you could add to
> the list with a context menu, IIRC, but the main way was always in the
> Control Centre, File Associations section.  In KDE4 it's in
> SystemSettings > Advanced tab > File Associations.  Add to the list any
> applications that you want to associate with the file type, remembering
> that the top one in the list will be the default - again, exactly as it
> was in KDE 3.

Read that double-quoted part again, Anne, it's not file associations but
device actions that "generic" is talking about.  I don't remember the
details of how kde3 handled that, but kde4 is far more hal-action-centric
in that regard.  Unfortunately, hal isn't the most intuitive thing around
to try to configure.

In fact, having done a bit of it myself, I must say configuring hal can
easily be obtuse to the point of extreme frustration even for someone
accustomed to dealing with bare text config files and who was configuring
and compiling his own kernel even before he chose his email program on
Linux.  It might be designed to make plug-N-pray possible for the Linux
newbie, but God help the poor soul who finds it doesn't do quite what he
wants and decides to try to configure the thing!

With the GUI style device (notifier) actions config, KDE has done an
exemplary job of making the extremely obtuse reasonably possible, but
there's simply no getting around the fact that what's being configured is
complex and obtuse to the point of challenging even the hardcore Linux
geek, and even with KDE's best efforts at simplification and a GUI config
to work with, it's not a simple thing to configure.  But I'll take it any
day over the obtuseness of hal's textfile config, that's for SURE!

Anyway, I'm working on a longer explanation myself.  But you know how
detailed I get, and that takes time...

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

[Anne Wilson-5]

On Friday 30 October 2009 15:49:56 Duncan wrote:

> Anne Wilson posted on Fri, 30 Oct 2009 12:10:28 +0000 as excerpted:
> >> Looking in the control center under device actions left me stumped
> >> trying to figure out how to change that so I can choose Open with File
> >> Manager.
> >>
> >
> > Basically it is exactly the same as in KDE 3.x.  The context list is
> > affected by your choices in File Associations.  In 3.x you could add to
> > the list with a context menu, IIRC, but the main way was always in the
> > Control Centre, File Associations section.  In KDE4 it's in
> > SystemSettings > Advanced tab > File Associations.  Add to the list any
> > applications that you want to associate with the file type, remembering
> > that the top one in the list will be the default - again, exactly as it
> > was in KDE 3.
>
> Read that double-quoted part again, Anne, it's not file associations but
> device actions that "generic" is talking about.  I don't remember the
> details of how kde3 handled that, but kde4 is far more hal-action-centric
> in that regard.  Unfortunately, hal isn't the most intuitive thing around
> to try to configure.
>

You're right, of course.  I read it as 'context menu' presence.  I don't know

the answer to this, but it might be buried in one of the .desktop files in
/usr/share/kde4/services.  I know krunner gets info from there, and many other
things look there for 'keywords'.  It's obviously not something you are
intended to alter, but if you find it, I don't see why not.  I don't actually
ever remember seeing the facility to alter it in KDE3 either - where did you
do it there?

Anne
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature?  Add it to UserBase


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

[Duncan-2]

genericmaillists posted on Thu, 29 Oct 2009 22:02:49 -0400 as excerpted:

genericmaillists posted on Thu, 29 Oct 2009 22:02:49 -0400 as excerpted:

genericmaillists posted on Thu, 29 Oct 2009 22:02:49 -0400 as excerpted:

> The control center in KDE4 is confusing and limited compared to
> KDE3.5.<br><br>Setting up device PNP actions was relatively straight
> forward and easy to figure out in KDE3.5 but that does not seem to be so
> in KDE4.<br><br> When I put a movie DVD in the CD/DVD-ROM drive I get
> five available actions. One of those actions is Open with File
> Manager.<br>When I put a music CD in the CD/DVD-ROM drive I get three
> available actions. The Open with File Manager or Play with Amarok is not
> in the list to choose.<br> <br>Looking in the control center under
> device actions left me stumped trying to figure out how to change that
> so I can choose Open with File Manager.<br><br>Clicking on Help did not
> make it clear either.<br><br>Is there any documentation available that
> does explain this so a person new (not new to KDE or Linux) to the KDE4
> environment can learn how to do this?<br>

Please turn off the HTML when posting to lists.  Some readers find it
annoying, as their client may not handle HTML, or if it does, they may
have that feature off for security or other reasons.

As for your question... I took a look at it here, running kde 4.3.2 (you
don't mention what particular kde4 you're running, unfortunately).

Kde4 is obviously rather more integrated with hal, and policykit if you
(or your distribution) enabled that at installation.  As such, it's setup
to deal with things using the information they provide, such as various
device properties.  The logic is boolean (that is, true/false, on/off, no
in-betweens).  A condition is either true or false, and groups of
conditions can be combined with a logical OR (any one must match) or a
logical AND (all must match) to fill a condition at the next higher level.
 If the top-level condition (which is generally a logical ALL or OR of
lower level conditions) matches when a device becomes available, that
action is shown as one of the ones available to choose from.

There's also a place to fill in the command that the action triggers when
chosen.

You want to be able to open a music (presumably CDA, CD Audio) disk using
the file manager.

First, understand that a music disk isn't really composed of files, per
se.  It's one long data stream, with the data track a spiral much like
that of an old vinyl record, except in digital rather than analog. There's
timestamp information that enables a CD-player to skip to a particular
audio track, but that's just a portion of the data stream, not really
individual files, as the concept is normally understood in computer terms.
 What you used to see when opening the disk in kde3's konqueror was a
"virtual" filesystem, created by by KDE's cda ioslave, making it appear
that there were actual files on the disk that could be copied elsewhere,
even tho they didn't really exist as such, and what kde was doing thru the
ioslave was actually converting the data into the desired format
on-the-fly.  The cda format is very close to "raw", in that it's just that
track streamed off the disk.  That's what many other systems such as MS
Windows normally expose as well.  But there's not a real filesystem on the
CDA disk, and it can't be mounted as such -- try it, mount gives an error.
 The additional formats that were viewable, however, were converted from
cda format to mp3 or whatever, on the fly. That's probably why it's not
listed to be opened using the file manager by default, now, because it's
not really a filesystem to be browsed, in the same way that a data CD or a
data session on a mixed-mode CD would be.

A DVD, unlike an audio format CD (aka CDA), uses the UDF filesystem, with
2K data-blocks according to the spec, corresponding rather closely to the
1/2k sector size and usual 2-8k block sizes of various other filesystems.
Like the ISO9660 filesystem on a data-CD, but UNLIKE the filesystemless
CDA format, this is a real filesystem and can be browsed as such, so it
makes sense for the choice to browse the filesystem to be listed as one of
the available options, and it is, by default.

Do note that if you have a (still alpha I believe, but reasonably
functional tho without a help manual to browse, version 1.68.0_alpha3
installed here) kde4 version of k3b installed, you *WILL* have a couple
additional actions available, as supplied by k3b.  Here, in addition to
the ones you may have, I have:

* Extract Digital Audio with K3b

* Copy with K3b

The first would do the conversion that kde3's cda ioslave used to do on-
the-fly, ripping to your choice of ogg-vorbis, wave, flac, or mp3, based
on the encoders you have installed for k3b to use and your choice in the
ripping dialog.  The second simply copies aka clones the CD to a second
one, optionally keeping the iso image on the computer's normal filesystem
to burn additional copies off of.

Of course, if you wanted to try it, you can edit the Open with File
Manager option, which looks like this, here (* indicates nesting level)...

--------------

Any of the contained conditions must match

* All of the contained conditions must match

* * Any of the contained conditions must match

* * * The devices property StorageVolume.usage must equal 'FileSystem'

* * * The devices property StorageVolume.usage must equal 'Encrypted'

* * The devices property StorageVolume.ignored must equal false

* All of the contained conditions must match

* * The device must be of the type StorageAccess

* * The devices property StorageDrive.driveType must equal 'Floppy'

--------------

So, taking it backward.  from the bottom...

1) The bottom two conditions are children of the third from the bottom,
which says both must match (a logical AND).  The bottom two in simple
terms just require that the device be floppy drive.  If it's a floppy,
therefore, both match, and their parent is true as well.  Since /its/
parent is the top-level logical OR (any must match), if it's a floppy, the
conditions match all the way up the tree and action is shown.

But we're talking about a CD here, not a floppy, so that doesn't apply.

2) The other nested set of conditions is a bit more complicated.  Still
from the bottom...

2a) The device can't be set to ignored in hal's config.  Simple enough. It
should be safe to assume that's not the case or the other choices likely
wouldn't appear either.

2b) The other peer condition is a compound OR (any must match), which
basically requires that the device usage must be either filesystem or
encrypted. If either of those are true, the compound OR matches.

2c) So, now we're talking about a (1) non-floppy that (2) isn't ignored
and (3) is either encrypted or a filesystem.  If that's the case, then
this branch of the logic tree is true, and the whole logic tree is
therefore true since the top-level parent is a logical OR (any true
children make it true as well).

It should be obvious what the problem is.  Our CDA doesn't have a valid
filesystem, and it's not encrypted either, so it's not filling that
condition and the action doesn't appear.

If you wish, you should now have enough information to add a new action
with what you want.  (I'd suggest not messing with the existing actions,
just in case.  It's a lot easier to remove an added action than it might
be to fix a screwed up edited action.)  Find one, say Play with KsCD, that
looks like what you want, and make the new one look like it, except change
the command and the icon, of course.  Do note that changes don't seem to
actually take effect in the device notifier until you restart KDE.  (It
should be possible to terminate and restart just one component... if I
knew which one... Maybe just plasma-desktop?  I didn't try it.)

But I tried the filemanager thing with a CDA just to see what it would do,
and while after restarting kde the action did show up, it didn't do
anything.

But you could probably setup a play with Amarok that would likely work
better...  I decided amarok was going some other way than what I was
interested in and don't have it installed anymore, so I can't test that,
but I did test creating an action with the same conditions as the KsCD
one, but using a different command, and that worked fine.  (Incidentally,
it appears existing actions can be edited and the edits are picked up
immediately.  Deleted actions seem to be deleted immediately as well.  
It's only adding actions that seemed to require the kde restart to be
picked up, for whatever reason.)

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

[genericmaillists]

Thanks for the very detailed explanation. I was trying to create a new
option to open with Amarok last night but was getting errors.

I am running kde 4.3.2

I was trying to create the new option to be set up like the one that
is already there for KsCD but it would not work. While I was typing
this I tried this:
I edited the KsCD option by changing the icon, the name, and the
command line choice and it worked.

Now I need to see if I can get the open with file manager changed.
___________________________________________________
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.

[genericmaillists]

On Fri, Oct 30, 2009 at 3:42 PM,  <genericmaillists@...> wrote:

> Thanks for the very detailed explanation. I was trying to create a new
> option to open with Amarok last night but was getting errors.
>
> I am running kde 4.3.2
>
> I was trying to create the new option to be set up like the one that
> is already there for KsCD but it would not work. While I was typing
> this I tried this:
> I edited the KsCD option by changing the icon, the name, and the
> command line choice and it worked.
>
> Now I need to see if I can get the open with file manager changed.
>

Scratch that I was able to make the edit change in the dialog box but
even after a re-boot the old KsCD option is still there and not the
edited one. Making changes or additions from the kde control center
seems to do absolutely nothing. That is probably why the new option I
was trying to create first would not take. I am beginning to hate this
new kde. I had no problem doing what I wanted when I was in kde3.5.
___________________________________________________
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.

[Duncan-2]

genericmaillists posted on Fri, 30 Oct 2009 15:58:41 -0400 as excerpted:

> Scratch that I was able to make the edit change in the dialog box but
> even after a re-boot the old KsCD option is still there and not the
> edited one. Making changes or additions from the kde control center
> seems to do absolutely nothing. That is probably why the new option I
> was trying to create first would not take. I am beginning to hate this
> new kde. I had no problem doing what I wanted when I was in kde3.5.

In my tests, I had the same problem trying to edit an existing option,
which is one reason I suggested you add a new option.  With a bit of
thought and intuition, based on my knowledge of Linux and how KDE works,
I think I know what's happening, and that it's simply KDE's poor (as in,
almost non-existent, or where it gives one, it's the wrong one) error
reporting in regard to this.

Keep in mind that the kde environment a user actually interacts with is
an amalgamation of upto four or even five different levels of settings,
some of which may conflict with each other, and KDE has to make sense of
it all and present some semblance of reason to the end user.  One of the
places where kde4 still falls short of kde3 is in stuff like the error
reporting, etc, that kde3 had years to work out -- and even more so
because kde3 was apparently not the nearly ground-up rewrite that kde4
was, so they had the years of kde2 as well to get the edges smoothed out
in stuff like error reporting.  kde4 has almost the same base
functionality, but there's still a lot missing in terms of what it does
when something goes wrong, there's still a lot of bugs, the functionality
might be there but the errors aren't reported properly when something
does go wrong, etc.

Those multiple layers are this:  There's what KDE ships as the defaults
(#1).  There's the modifications to those defaults that the distribution
ships (#2).  There's the modifications to /those/ defaults that a
sysadmin might choose at install time, what packages he installs, config
changes he makes, etc (#3).  There's possibly additional changes made at
the system/operational level by the sysadmin after installation (#4).  
Interacting with all of this at multiple levels are the freedesktop.org
desktop standards that Gnome and KDE both try to follow for interop
purposes.  Thus, a change made to the Gnome config by the distribution
(at #2) or the sysadmin (at #3 or #4) can adversely affect the KDE
environment as well, if it's made to the desktop standard config.

All that's combined at the system level.  Then there's the actual user
config on top of that (#5), which has its own parallel desktop standards
config that might adversely affect it too.

What the user sees is the accumulation of this stack, hopefully with the
user prefs at the top, overruling defaults at other levels, EXCEPT where
overruled in turn by sysadmin policies (as opposed to defaults).  If
there's a bug in assembling all of this into some cohesive presentable
whole, it's the user at the end left trying to figure out what happened,
ideally with the help of accurate error messages.  But as I said, it's
exactly that, the (lack of) smoothness of well tested and honed over time
error messages, plus the usual level of bugs that haven't yet worked
themselves out at this stage in the game, that is where kde4 is lacking
ATM.

So how does all this apply to the situation at hand?

Well, if my intuition is correct, those existing actions are in some
config file at the system level, and they aren't directly editable by the
user, because the user doesn't have permissions to edit system config
files, only his own config.  Now what /should/ happen in that case is one
of two things.  Best would be if those actions appeared with a clearly
distinct marking setting them off as system actions, with some button
available to be pushed that would after appropriate authorization, stick
the editor in superuser mode so the user could edit the system settings.  
Lacking that, kde should at least have appropriate error messages if an
attempt is made to edit the settings, saying they're system settings, and
can't be edited as a normal user.  But because kde doesn't have all those
nice rounded edges yet, what ACTUALLY happens is that either the wrong
error pops up (the one I was getting in my tests, saying something's
invalid with the settings, even if one simply hits edit, then OK, without
changing a THING!), or NO error pops up, the settings appear to change,
but nothing actually changes, which appears to be what you were seeing.

But, because I'm not at all sure it's a good idea to go messing with
those defaults anyway, at least until you're absolutely sure you know
what you're doing because you've tested it, what I suggested was to setup
a *NEW* action, complete with its own conditions, etc.  Copying one of
the default/system actions is fine, just change at least the icon or the
name or something so you can tell it from the default system action.

That actually solves two issues at once.  First, it solves the uneditable
default settings problem, whether the root is as I intuit or something
else.  Second, it /does/ save one from themselves, since you're now
editing a new action and can't screw up the defaults.  You can always
delete your new action if you don't like it, and it should remain
possible because it's actually your action, in your home configuration,
not in the system configuration.

So anyway, that's what I suggest doing.  Live with the default actions,
ignoring them if you need to, while creating your own.  You can modify
those to your heart's content, or at least, I was able to modify the new
ones I created here, without getting the errors that trying to modify the
system ones gave me, even when those errors were clearly incorrect.

Remember, as I said, at least in my testing, creating the actions
required a kde restart to have them show up.  However, once created, I
could modify them, or delete them, and the effects would show up
immediately.  Just leave the default ones alone, only using them as rule
references where needed when creating your own.

Hopefully, that works for you as it did for me.

Meanwhile, someday, kde4 will be as nicely smoothly functional as
kde3.5.10 was.  However, it's self-evidently nowhere near there yet.  
Many people including myself have been predicting that by the time it
gets to 4.5, it'll be actually usable at the level that kde3.5 was.  
There will still be bugs and missing documentation and etc, but then kde3
still had bugs and in its case, sometimes stale documentation, as well.  
But with 4.5, we're predicting that a normal user should find it normally
functional.  

I've said it before and I'll say it again.  4.0 was really a very early
alpha or conference technology preview release, hardly functional at
all.  4.1 was a late alpha or early beta release, sort of functional, but
not quite everything showing up yet and a LOT of stuff still broken.  4.2
was a late beta release, things were shaping up and it was almost usable
by those crazy folks (like me) that actually like beta testing, tho it's
not something I'd call anything near ready for ordinary users (as KDE
did).  4.3 continues the improvement, approximating an early rc.  Most of
the worst show-stopper bugs are worked out, but there's a LOT of work
left to do on polish, documentation, error messages, etc, and it's still
not something you'd want your ordinary users trying to deal with.  Given
the pattern, 4.4 should shape up as a late rc, or a .0 release when
marketing says it needs to be out even if the engineers don't fully
agree, getting real close to full release quality, but still some missing
finishing touches.   Also, there's now getting to be enough third--party
application support that it's generally usable as a platform.  Based on
my following of kdeplanet and the lists, knowing the 4.3 bugs already
fixed for 4.4, etc, I'd say that's squarely where 4.4 should be by
release in February.  4.5 should then finally be ready for mainstream
use, a "proper" X.0 release, more practically what most release end up
with for their X.1 release.  Given six month release cycles, by this time
next year KDE should be sitting pretty... right about time Gnome 3 is
getting the fallout from /its/ changes! =:^P

Meanwhile (2), we really should check and see if there's bugs filed on
this yet.  Please confirm whether you see the same thing I did, that
creating your own actions works, and either do the bug if you like, or
ask me to.  That way, maybe by 4.5, we /will/ actually have at least
reasonable error messages here, instead of the "some settings seem to be
invalid", even when nothing's changed from the factory defaults!

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

[genericmaillists]

> Meanwhile (2), we really should check and see if there's bugs filed on
> this yet.  Please confirm whether you see the same thing I did, that
> creating your own actions works, and either do the bug if you like, or
> ask me to.  That way, maybe by 4.5, we /will/ actually have at least
> reasonable error messages here, instead of the "some settings seem to be
> invalid", even when nothing's changed from the factory defaults!
>

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

[Duncan-2]

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.