KDE4 Control Center confusing

[Duncan]

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.