[kde-linux] Execute at login for KDE only

[Duncan]

Mark Knecht posted on Tue, 25 Sep 2012 10:17:06 -0700 as excerpted:

> On Tue, Sep 25, 2012 at 9:49 AM, Dale <rdalek1967 at gmail.com> wrote:
>> Mark Knecht wrote:
>>> 
>>> If I wanted to run xset when only when logging into KDE, but not
>>> for other environments like razor or fluxbox, how would I do that?
>>>
>> I think this is what you want.  Go into System Settings then at the
>> bottom click on Startup and Shutdown.  Autostart should be highlighted
>> on the left and you can add scripts and such from there.
> 
> Thanks Dale. That seemed to have worked. Now after logging into KDE I
> have DPMS disabled which makes watching long videos while I'm working on
> another machine nice.
> 
> I don't see how to undo this command on log out (i.e. - xset +dpms) but
> at least for now it's manageable.

Provided you use a script (not a desktop file, aka program, and the 
condition in the next paragraph must be met), you can do the same thing 
for shutdown as well.  Simply add it as for startup, then click the 
dropdown box and select shutdown instead of startup.

FWIW, this and most of the rest of the detail below is covered in the 
help as well.  If it's installed, you should be able to simply hit the 
help button in the autostart config GUI, and get kde's version of all 
this.  But there's more detail below than in the help, as I use this 
functionality quite extensively myself, and thus have quite some 
experience with it. =:^)

One additional condition, however.  For startup it doesn't matter, but 
for shutdown (or pre-kde startup, if you choose that option), the 
script's (or symlink's) extension must be *.sh -- the name must fit the 
shell-pattern *.sh .

Further discussion:

This entire autostart (including shutdown) module is simply a GUI front-
end to managing multiple different directories.  Any files of the 
appropriate type placed in these directories will be executed at the 
appropriate point in the startup/shutdown process.

1) The freedesktop.org standards mandate one such directory, 
$XDG_CONFIG_HOME/autostart .  If $XDG_CONFIG_HOME is unset, that defaults 
to ~/.config, so the dir defaults to ~/.config/autostart/

FWIW, I prefer to SEE my config files so dislike "dot-file" hidden 
configs.  Thus, I've set XDG_CONFIG_HOME=$HOME/config (not dot-hidden!), 
so the location I see here is ~/config/autostart/ .

There's two (possibly more) kde parallel directories as well, system and 
user.  The system director(y|ies) can be found in $KDEDIRS/share/
autostart or $KDEDIR/share/autostart.  ($KDEDIR, singular, is a legacy 
setting, $KDEDIRS allows multiple system locations.  See the kde 
sysadmin's guide on techbase.kde.org for more.)  The default location if 
neither variable is set is build-specific, depending on how kde was 
configured when it was built, but a common setting is /usr/, making the 
system dir location /usr/share/autostart/.  SYSTEM ENTRIES ARE NOT SHOWN 
IN THE KDE AUTOSTART GUI FRONTEND, HOWEVER.  I guess the folks who 
designed the frontend decided that'd be confusing, and of limited use as 
well, since under normal conditions they couldn't be directly changed 
from the front-end due to lack of permissions, anyway.  But if you check 
the appropriate system dirs, you'll see the *.desktop entries for the 
various kde components kde normally starts as part of a kde desktop 
session.

KDE of course directly mirrors the system config tree layout in $KDEHOME, 
which if unset, defaults to ~/.kde as shipped by kde, but many distros 
change that to ~/.kde4, as they likely had a ~/.kde3 at one point and may 
in the future have a ~/.kde5 as well.  So the user location parallel to 
the system location will normally be ~/.kde/share/autostart, tho some 
distros will have .kde4 instead of .kde.

(Again, I don't like dot-hidden, so $KDEHOME=$HOME/kde, resulting in 
~/kde/share/autostart in my case.)

Any freedesktop.org standard *.desktop files found in these dirs will be 
run at startup of any compliant desktop environment.

The standard provides a method to specify that such *.desktop files apply 
to only specific environments, via a line in the desktop file, 
"OnlyShowIn=KDE", to only execute it with kde.  (*.desktop files are 
primarily used for menu entries, thus the name of the "OnlyShowIn" key.  
But their purpose and format has been extended to a number of other uses 
as well, including this one.)

Another line, "Hidden=true", will disable the entry.

This is the "program/desktop file" interface provided by kde's autostart 
frontend.

Clicking the add-program button lets you browse the existing menu for 
*.desktop entries, with the ability to create a new *.desktop file "from 
scratch" if you simply type in the name of an executable that doesn't 
match anything in the menu. Once you hit OK, the *.desktop file is 
created/copied into $XDG_CONFIG_HOME/autostart/, where you can access or 
edit it just as you would any plain text file.  (If you add entries via 
kde's autostart GUI frontend, it appears to use the XDG_CONFIG_HOME 
location.  However, kde itself seems to use the */share/ locations for 
its config, the system defaults in $KDEDIR(S)/share/autostart, user 
defaults in the parallel $KDEHOME/share/autostart.  Thus, you may 
actually have *.desktop files in all these locations, as I do, with kde 
checking them all and starting those that aren't disabled or for other 
desktop environments only, when it starts.)

Of course since the kde autostart front-end is simply displaying the 
*.desktop files found in these locations, once they're there, the entries 
show up under "Desktop Files" in the front-end as well (with the 
exception mentioned above, system entries don't show up in the GUI, only 
user entries).  But it doesn't matter how the entries are created.  You 
can create them via the front-end, or by copying/creating the files via 
your file manager or text editor of choice, and of course the system 
locations will have entries setup by the kde installation process and/or 
local sysadmin, as well.

Back in the kde autostart frontend, in the status column of each 
*.desktop file entry it found, there's an enabled/disabled checkbox.  If 
it's unchecked, a "Hidden=true" line is added to the *.desktop file.  If 
it's checked, any such line in the *.desktop file is removed.

If you click the properties button, you get kde's standard multi-tabbed 
*.desktop file properties dialog.  The general tab lists the file name 
(editable if file permissions allow it), icon (click to select a 
different one, again assuming file permissions allow), location, size, 
and times.  The permission tab is the standard kde file properties dialog 
permission tab, information... must be semantic-desktop related, I have 
that disabled (USE=-semantic-desktop on Gentoo), so the tab is blank, 
here.  Preview is the normal plain-text file preview listing, where you 
can see the actual hidden/disabled and kde-only lines if they apply, 
along with other *.desktop settings.

If you click the advanced button, you get the option to set kde-only, or 
not, which controls the OnlyShowIn= line in the file.

Pretty slick front-end, isn't it?  The limitations of the desktop file 
interface include not showing system location entries, only working for 
startup (not shutdown or pre-start), and an inability to directly edit 
the *.desktop files as-text from the interface itself, thus limiting 
editing to only those aspects that the interface directly allows.  Of 
course you can get around part of those limitations by working with the 
*.desktop files themselves, using normal file management and text-editing 
tools, but *.desktop files are still limited to startup only, since by 
definition, they're defined to work within the X environment, so there's 
nothing for them to run in when X shuts down or before it starts up.


2) That covers the *.desktop file interface, but there's the scriptfile 
interface as well.  There are three directories that apply here, one each 
for autostart, pre-kde-start (for setting the environment that kde uses, 
etc), and kde-shutdown.

2a) The autostart location defaults to $KDEHOME/Autostart, altho this 
location is further configurable in the paths module (kde settings, 
common appearance and behavior, account details, paths, I mentioned I 
don't like dot-hidden, I prefer all lowercase as well, so the location 
here is ~/kde/autostart/, not the default ~/.kde/Autostart/).

Back in the autostart GUI frontend, hitting the add-script button will 
let you choose an existing script, and you can choose to copy or symlink 
it into the autostart dir.  

Of course, you can accomplish the same thing by simply adding a script or 
symlink to a script to the appropriate autostart dir, via standard file 
management or text editing tools.  Among other things, this allows you to 
create a script specifically to run at kde startup, instead of copying/
symlinking one from, presumably, some place in your path, where you could 
run it by name only, from the run dialog or from a text terminal such as 
a konsole window.  If you have no reason to run it OTHER than at kde 
startup and you don't want it cluttering up your tab-completion path at 
the shell prompt, directly creating the file in the autostart dir may be 
appropriate.  Alternatively, you can copy (not symlink) a script there 
from elsewhere, thus allowing you to edit and customize only the kde 
autostart script, while leaving the original script in its original 
location as it was.

One thing I have *NOT* checked is whether scripts in this dir must have 
execute permissions set, for kde to run them.  Obviously, that'd normally 
be the case for something copied/symlinked in, but if you create your own 
scripts in that dir, they'd normally not have the execute bit set until 
you specifically set it, and I don't know if they'd run without it set, 
or not.

Additionally, I've never checked whether any ordinary executable will 
work, or whether it *HAS* to be a shell-script.  Of course, even if it 
has to be a shell script, it can still be a simple wrapper, that just 
invokes the non-shell executable, if that's all you need to do.

2b) That leaves the pre-kde-start scripts, found in $KDEHOME/env/ , and 
the kde shutdown scripts, found in $KDEHOME/shutdown/ .   In general, 
these work exactly like the autostart scripts, with a few exceptions:

2b1) Unlike the scripts autostart dir, I know of no way to customize the 
shutdown and environment dir locations, beyond changing $KDEHOME or 
altering the source code, of course.

2b2) As mentioned at the top, unlike script autostart, kde-shutdown and 
environment/pre-kde-start require that the script or symlink use the *.sh 
extension.  Of course the symlink functionality allows a workaround to 
that, by simply naming the symlink *.sh, regardless of what the script it 
points at is actually named.

2b3) When adding a script in the GUI-frontend, it defaults to startup.  
If you're using the GUI, you have to add a script (named as required for 
2b2) as startup first, before switching it to kde-pre-startup or shutdown 
if desired, by selecting the appropriate choice from the dropdown box.

This detail confused me at first, as I saw no way to configure something 
to run at shutdown --  despite the name of the section being startup and 
shutdown, all I could find when I was looking for a way to configure a 
shutdown action was autostart!  (I guess it's rather like MS Windows in 
that way.  The joke from MSWormOS 95 on was that you hit the start button 
to shutdown.  In KDE, you change what happens at kde shutdown by going to 
the startup config!)


With all those options and with both the GUI front-end and the file 
interface to work with, at least as far as run at startup/pre-start/
shutdown, kde really does live upto its reputation for being incredibly 
flexible, allowing you to configure pretty much any aspect of its 
functionality you might imagine, with a GUI front-end to that 
configuration that exposes far more than most kde alternatives, while at 
the same time allowing users and admins access to the bare config in as 
simple a way as possible, filesystem trees and plain-text config files, 
for those who want to go beyond the already expansive choices exposed in 
the GUI. =:^)

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