Autostart locations in KDE4
Duncan
1i5t5.duncan at cox.net
Thu Jun 2 15:54:03 BST 2011
Tim Edwards posted on Thu, 02 Jun 2011 11:53:52 +0200 as excerpted:
> Recently I found that knetworkmanager wasn't starting up when I logged
> into KDE. I tried looking for any mention of it in the 'startup and
> shutdown' control centre module, but no luck. Eventually I found a tip
> on a forum that I had to set 'Autostart=true' in
> ~/.kde4/share/config/networkmanagementrc
FWIW I don't use networkmanager at all, here. I have two main systems
here. My workstation is setup with a constant wired Ethernet connection
that's started as one of the system init services. My netbook... isn't
really used as a /net/book but rather as a portable un-networked computer
most of the time. Its Ethernet, which I use for updating from the
dedicated 32-bit chroot system image on my otherwise 64-bit workstation,
is likewise initscript controlled but in a non-default runlevel, and its
wireless hasn't been a big priority for me. I did try to get the netbook
wireless networking running at one point but failed, I believe due to a
kernel bug with the particular kernel I was running at the time. I've
since upgraded kernels but as I said, it hasn't been a big priority to get
that working, and I've not gotten back to it.
As such I can't and won't attempt to deal with the networkmanager stuff at
all. However, I can help with the following...
> So my question is, what's the status of the autostart stuff: Shouldn't
> it all be configurable through the standard control centre module which
> stores its settings in the standard (~/.config/autostart)
> directory?
Not really. The setting found in that location serve a specific purpose
-- USER configurable autostart (and auto-stop). It's not for general KDE/
desktop services (there's a different place to configure that) or for
general system services (configured using whatever tools your distribution
provides for setting up and configuring system initscripts and services).
> Does KDE go scanning through ~/.kde4/share/config/ looking for
> 'Autostart=' in rc-files?
I don't believe so in general. However, knetworkmanager is evidently (the
caveat about my not running it here applies, thus "evidently", based
purely on the evidence you reported above) available as a kde desktop
service if so configured, and this is /evidently/ the config-file location
where that preference is stored. Presumably there's also a GUI option
controlling it somewhere, but since I don't have the software installed, I
can't be sure where that might be.
But, I can explain a bit more about autostart in general...
First, it's useful to name the ways that kde does autostart. These are
the ones I am as a user aware of, in general from the surface-most to the
deepest infrastructure:
1) KDE session. This is controlled via kcontrol[1][2], system
administration, startup and shutdown, session management, under "on login".
If you set restore previous session (as I have), kde will restart the apps
that you had running when you logged out, with the exception of anything
listed in the exceptions list.
Alternatively, you can elect to restore a manually saved session. The
help for this item says that if it's checked (I don't know since I use the
restore previous session option), there's a save session option added to
the leave menu, along with the others.
The third alternative is to start with an empty session.
At this level, kde autostart is controlled by whatever it found running
when it saved the session, either when that option was chosen if save
session is set, or at logout, if that setting is set. If you use empty
session, you're simply telling kde not to autostart anything at this level.
2) The autostart functionality I believe you were referring to. The GUI
for this is kcontrol, system administration, startup and shutdown,
autostart. The GUI provided actually controls four different launch
options with differing purposes in one place.
2a) Desktop files. This is the freedesktop.org standard *.desktop file
launch option. The *.desktop files in question can be found in
$XDG_CONFIG_HOME/autostart. The default for XDG_CONFIG_HOME if that
variable is unset, is $HOME/.config/, so the default location is
~/.config/autostart/ , if you wish to manually add your own *.desktop
files. Once they are added, if you select one and hit advanced, there's
an option to autostart in kde only, which adds an appropriate line to the
*.desktop file. If this isn't set, any freedesktop.org compliant
environment (gnome and xfce I believe, probably others as well) should see
and launch these apps when the user logs in.
2b) What the kcontrol autostart GUI lists as script files is actually
three separate options, as once you add a script using the GUI, there's a
dropdown box allowing you to select startup, shutdown, or pre-kde-startup.
Scripts in question should be set executable and named as *.sh. (The
startup option lets you use any name, but if you change it to shutdown or
pre-kde-startup you'll get a dialog suggesting a *.sh name if it's not
named that way to begin with.) If you're selecting a preexisting script
as you will be if using the GUI, it lets you either copy it or symlink it
into the appropriate directory as desired. Alternatively, you can place
the script (or symlink) in the appropriate dir as described below.
2b1) The directory for script startup can be checked/set in kcontrol,
common appearance and behavior, account details, paths. I've changed mine
but I believe the default is either $KDE_HOME/autostart/ or $KDE_HOME/
share/autostart/ , possibly capitalized as Autostart. If $KDE_HOME is
unset it defaults to $HOME/.kde/ as shipped by kde, but many distributions
change that to $HOME/.kde4/ .
This directory/option parallels the *.desktop option, but it's for *.sh
scripts, not *.desktop files
2b2) The script shutdown dir is $KDE_HOME/shutdown/ .
This obviously parallels script startup but for shutdown.
2b3) The script pre-kde-startup dir is $KDE_HOME/env/ .
Scripts set here will be run before kde launches. As should be obvious
from the directory name, the most frequent use is to set/export
environmental variables that all apps run in the session will inherit.
3) kde services. These are controlled via kontrol, system administration,
startup and shutdown, service manager. As I said above I don't have
networkmanager or knetworkmanager installed, but my guess is that you
might find the entry you were looking for here.
It's also possible that you'll find related settings in kcontrol,
hardware, information sources, under network management backend. FWIW, I
don't have anything installed for any of those, so it's fake or invalid
entries for all three backends (net, remote control, modem) there.
---
[1] kcontrol: Known as systemsettings in kde4 as shipped by kde, I
continue to use the more accurate kde3 term, kcontrol. It's more accurate
because system settings should logically apply to... the system! not to
user specific kde-only settings. With certain exceptions, the settings
available here are kde only-- they won't apply if the user logs out of kde
and into say gnome or xfce, and they normally control EXCEPTIONS to kde's
STANDARD settings found in /usr/share or the like, applying these
exceptions to ONLY the user who sets them and storing them in that users
home dir, so they don't apply globally to all users either. Ergo, for the
most part we are *NOT* talking about system settings and calling the app
that applies them systemsettings is simply inaccurate and confusing.
Meanwhile, even when it *IS* global systemsettings (say if a user sets the
clock using the date and time module), it's the KDE-specific way of
setting them, not for instance the date command run as root at the command
prompt, so the term kcontrol isn't inappropriate even in /that/ case. I
simply choose to continue using the more correct kde3 term, even if tho it
means an explanation such as this to avoid confusion in every post where I
do so.
Meanwhile, it's worth noting that certain distributions add their own
modules here that are actually systemsettings. But the fact remains that
there's enough NON-system settings here that apply to only kde and only
the specific user that sets them, that even in that case, kcontrol remains
arguably more accurate. Plus, these are distribution modules not shipped
by kde, while it's kde's as-shipped name under discussion.
[2] The kcontrol layout changed substantially in kde 4.5. If you're
running an earlier version, the module path and names are likely
different, but they should still exist under different names, if you look
for them.
--
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.
More information about the kde
mailing list