On Fri, 03 Jun 2011 11:28 +0000, "Duncan" <1i5t5.dun...@cox.net> wrote: > Klipper actually does, tho it's not necessarily intuitive. > > If you select quit from the second menu (the one you get if you click the > tear-off, otherwise it shows only some of the possible entries and misses > the actual klipper app options, at least if you have it set to more > entries than the first menu shows normally, I have it set to 50... I'd > call the fact that it doesn't append the app options to the first menu a > bug...), in what would be the normal "are you sure" dialog, it instead > asks if you want to start it automatically when you login, with start, > do- > not-start, and cancel buttons (thus giving you the are you sure option > indirectly, as cancel). > > But selecting quit to configure whether you want to start it at login is > about as unintuitive as the infamous MS Windows start button... to > logoff/ > shutdown! > > Actually, I'd call /that/ the bug. It should have a rather more > intuitive > option to start at login directly in the klipper config dialog. You > shouldn't have to quit it to set that, altho having it in the quit > verification is a nice touch as well, but only as well, that shouldn't be > the ONLY way of setting it.
Your forgetting the problem that caused me to start this thread originally: When you disable one of these programs from starting with KDE by right-clicking on it and clicking 'quit' there is no way to re-enable them. There is no way to even see what's disabled or enabled - it just dissapears into the ether from the user's POV, like my KNetworkManager. The only way is if the user searches on mailing lists and forums and discovers that the 'clipboard thing' in their task bar is called kclipper or something and they have to edit a some config file. > > It's still not a bug not to appear in the /user/ autostart area, because > it's a kde service and is treated as such (the monochromatic icon is a > major hint), not an additional normal user app. > > Actually, I expect eventually they'll have it appear in the systray > "extra > items" list with a checkbox to start it there, much as they do device > notifier and event notifier (notifications). If you check existing bugs, > there's still menu/window/shortcut bugs open resulting from the 4.5 move > to the monochromatic icons and system-tray services, and it really does > feel like what we have ATM is a hack-job temporary workaround designed to > get it workable after that, not the final UI solution it should be. > > But that's klipper. I really can't have a proper opinion on knetmanager, > since I don't have it installed, except that I don't believe it's a bug > not to show it in autostart unless you as the user have directly > configured it there, because that's what autostart is /for/, the stuff > you've put there yourself, not the system services stuff kde normally > handles on its own. And that's really an opinion about the autostart > kcontrol module, not knetworkmanager, except that knetworkmanager happens > to be one of the apps in question. Well maybe these things that are defined in /usr/share/autostart should appear as services in the Startup & Shutdown module, but they don't. However they are clearly a user setting - it's the user who disables them or (if they know which rc-files to edit) re-enables them, they aren't a system setting. To be clear: I mean the user should have the ability to enable/disable them for his user account, the equivalent of what he can do now only be editing the rc-files in ~/.kde4. Not that users should be able to delete or add the .desktop files from /usr/share/autostart. Tim ___________________________________________________ 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.
