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.