Autostart locations in KDE4

Sun Jun 5 10:24:17 BST 2011

Tim Edwards posted on Sat, 04 Jun 2011 14:26:24 +0200 as excerpted:

> On Fri, 03 Jun 2011 15:29 +0000, "Duncan" <1i5t5.duncan at cox.net> wrote:
>> Tim Edwards posted on Fri, 03 Jun 2011 14:05:32 +0200 as excerpted:
>> 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.
> 
> No, sorry but you're wrong about this. If you were right I would never
> have needed to search around on how to make KNetworkManager startup
> automatically. To prove it do a simple experiment:
> 1. Click on klipper icon and choose 'quit'
> 2. When it asks tell it not to automatically start
> 3. Logout, log back in and verify klipper didn't start.
> 4. Start klipper from the menu or krunner or wherever - it runs normally
> 5. Logout and log back in - no klipper
> 
> The point is that there is *no way* to re-enable these programs *except*
> editing the klipperrc or networkmanagerrc and setting autostart=true.
> Once you've closed them once they never start up automatically again
> from the normal user's perspective.

That's incorrect.  When you told klipper not to start automatically at 
boot, it obeyed.  You then started it again, logged out and back in, and 
it didn't start automatically, still obeying what you told it.

To get it to start automatically again, you do the same thing you did to 
get it NOT to start automatically, but choose the other option.

IOW, you start klipper, quit it manually so you get the quit dialog again, 
and... SURPRISE... tell it that you want it to start at login, again.

It should now do so, and you haven't edited the rc file manually in 
ordered to do it.

>> 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.
> 
> Again, look at the file location - ~/.kde4/share/config/<someprogram>rc
> - it *is* a user setting. If I set autostart=true or false in my
> klipperrc, or close klipper and tell it not to restart (which is the
> same as setting autostart=false) it is entirely separate from the way
> KDE manages system default entries. I'm saying that this functionality,
> the setting of autostart= in the user's own rc files, should be exposed
> in the GUI. There are already 2 separate sections in Autostart -
> .desktop files and scripts - there's no reason to not have a 3rd -
> 'default programs' or something with just an enable and disable option
> for each.

It's a user setting, but a user setting for a normal part of the kde 
desktop.

What I'm saying is that the autostart is for programs, kde or otherwise, 
that a user sets to run totally independent of the the normal kde desktop 
infrastructure.

IOW, pan is an gtk not kde app.  As such, there's no way to tell kde to 
start it as part of the kde desktop.  xset is an command-line friendly app 
that controls X settings.  It too is not part of the normal kde desktop.  
konsole is a part of the kde base platform, but its not part of the 
normally running kde background infrastructure, you normally start it 
directly.

In any of these cases, autostart can be used to start the app 
automatically, but the user specifically sets up kde to do so on his own, 
totally independent of the default kde system settings.

Actually, I have klipper manually added to autostart exactly the same 
way.  It starts klipper, normally part of the kde background desktop 
functionality, but it does so entirely separately FROM that normal 
background functionality.

The autostart functionality as covered by that kcontrol module is entirely 
separate from kde's normal "launches as part of kde" functionality, with 
entries that show up there indicating a direct action of the user to make 
it so, as opposed to the stuff kde normally does on its own because it's a 
part of the kde desktop experience.

I'm saying that the two mechanisms are separate, and should remain so.  
Having one appear in the other would only confuse the fact that it's a 
separate mechanism.  (However, see below for a change in my former 
position as described here.)

> Your suggested way of manually adding them back is a workaround, not a
> fix. It requires users to be able to find the name of the binary -
> klipper or knetworkmanager or whatever. Plus users have to know in the
> first place that to get these programs back they have to manually add
> them.  This is totally non-intuitive and for most users will require
> them to ask on mailing lists and forums.

As I explained in the earlier reply, no, users do NOT have to know the 
name of the binary.  Simply typing something about the functionality, in 
the klipper case "clip", in either krunner or kickoff, finds the program 
in question and offers it as an option.  It can do this because it 
searches the description field as well as the app-name field.

And as I said there, how would users even know they wanted it to run, if 
they weren't aware of the functionality?

> The basic principle is if the programs appear by default on a fresh home
> directory and can be disabled easily in the GUI they should be able to
> be re-enabled easily in the GUI.

And in general, it's there.  As I demonstrated for klipper, you reenable 
it in the GUI in exactly the same place you disable it, in the quit dialog.

Now I would happen to agree that the option should also be in the klipper 
configuration dialog (and that it's a bug not to have it there), because 
it's not exactly intuitive that you must "quit" klipper in ordered to find 
how to get it to automatically start, but that's not what you're 
proposing.  What you're proposing is a conflation of two separate 
functionalities into one.

That said...

This exchange HAS changed my viewpoint some.

I'll allow that the system autostarts could be displayed in the same 
autostart module, *PROVIDED* they are clearly separated into their own 
category, that makes the distinction explicit.  Basically, the idea would 
be a visual and functional separation much like that currently seen with 
the desktop/programs vs scripts functionality.

Add a separate section within the window for System Desktop Files, with 
the help button and a tooltip (and add corresponding tooltips for Desktop 
File and Script File) explaining the distinction.

As currently setup, the system files would simply be listed, with no way 
to change them, because the user doesn't have system permissions and 
because as explained above, the mechanism used to enable/disable them per 
user is entirely different.  But even simply having them listed would be a 
step in the right direction, as it would give the user yet another way to 
discover them and run them manually, to look for the in-app method to 
enable/disable them per-user.

But, a file-in-special-directory method similar to the current auto-run 
setup could be designed to disable these as well.  For instance, the 
current user scripts shutdown directory is $KDE_HOME/shutdown/.  A 
directory $KDE_HOME/disable-sysautostart/ or some such could be used. (The 
program/desktop-file dir is a freedesktop.org standard so its location is 
set by that, while the others are kde extensions, as this would be, so it 
would be under the $KDE_HOME/ location.)  If a *.desktop file copied or 
symlinked from the system dir were placed here, it would disable the 
corresponding system autostart entry, and the existing GUI with the new 
system section proposed above, could be a GUI front-end to managing that, 
much as it's a GUI front-end to the existing user autostart dirs.  This 
would require a change from the current per-application handling methods 
and would thus likely take some time to get them all doing the same 
thing.  However, just listing the system entries would already be a step 
in the right direction, even if they couldn't be dependably enabled/
disabled from there for a few versions.

I think that would address both your concerns of exposing that info in the 
same place for the user, and my concerns of keeping a visual and 
conceptual distinction, *PROVIDED* the UI managed that distinction, much 
as it already does the distinction between scripts and *.desktop files.  
But as I said, it'd take some versions to implement, especially since I 
believe the current situation is managed by each of these apps in its own 
way, and they'd all need to be changed to support the new method.

-- 
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.