Re: [kde-linux] Execute at login for KDE only
- Date: Wed, 26 Sep 2012 00:45:18 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde-linux] Execute at login for KDE only
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@xxxxxxxxx> 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 .
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
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
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,
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
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.