Re: Autostart locations in KDE4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Index of Archives]     [Trinity (TDE) Desktop Users]     [Fedora KDE]     [Fedora Desktop]     [Linux Kernel]     [Gimp]     [GIMP for Windows]     [Gnome]     [Yosemite Hiking]
  Powered by Linux