Autostart locations in KDE4

[Duncan]

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.