Tim Edwards posted on Fri, 03 Jun 2011 14:05:32 +0200 as excerpted:
> 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.
Sure they can be reenabled. Simply start them manually, hit the krunner
or kickoff hotkey and type into the box klipper. From the kickoff search
box, it shows up after three letters.
And those who don't remember what the thing that they just shut down was
titled in ordered to type it in can find it easy enough browsing the
kickoff menu. I didn't know where it was on the menu here but found it
pretty fast, because the only possible categories that made sense were
office (no, it's not there) and utilities.
Or, if that's too much, simply knowing that it's a clipboard tool (how
many people, even those still wet behind the ears from MS, don't know what
the computer clipboard is, or at least don't know and yet would still be
both inquisitive enough to have stumbled into accidentally shut the thing
off in the first place and perhaps more importantly, know enough about
what their missing to actually miss it -- if they even know enough to miss
it they should know at LEAST enough to associate "clipboard" with it!) and
typing clip into krunner... again comes up with klipper as an option.
The other apps should be similar. If you were talking about an app
without a menu entry it'd be one thing, but then, that'd be the bug, the
missing menu entry.
> Well maybe these things that are defined in /usr/share/autostart should
> appear as services in the Startup & Shutdown module, but they don't.
Actually, I wasn't aware that's where they were, but it's logical now that
I know, and I'm reasonably confident I could have found them if needed.
(For one thing, a quick package database query, equery belongs or equery
files, here on gentoo, to see what files match a partial name, tends to be
a pretty effective way to search for such things. I know as I routinely
use that method. =:^)
But now I know without actually having to go looking as you so kindly
posted the info. =;^)
> 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.
But that's my point. The user has the ability to add the entries to
autostart if they want to (and if they're already running there's already
a UI available to disable them), entirely separate from the way kde
normally manages the system default entries. And that's the way it should
be. The two setups should remain separate, so a user is always clear on
the entries he's added himself, vs those managed by the system.
--
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.
