Tim Edwards posted on Fri, 03 Jun 2011 11:02:09 +0200 as excerpted:
> Klipper also has no option to re-enable it's startup if
> disabled.
>
> This is not something most desktop users should have to do and defeats
the
> purpose of the Startup & Shutdown module.
>
> I'll raise a bug.
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.
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.
But if you put it there yourself (as I did kicker, note that whatever I
choose in that above should kicker start at login dialog, it doesn't
remove it from the user's autostart config, nor should it, since I put it
there myself and it should stay there until I remove it myself), THEN it
should be there. THAT would not be a bug. In fact, if kde added or
removed an entry in autostart based on any action other than the user
doing it themselves either thru the kcontrol/autostart module GUI or by
directly adding/removing the files from the associated directories, THAT
would be a bug. =:^)
--
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.
