WaldoBastianbastian@kde.org
&Philip.Rodrigues;
&Philip.Rodrigues.mail;
&kde; for Administrators&kde; InternalsOverviewto be writtenDirectory Layout&kde; defines a filesystem hierarchy which is used by the &kde;
environment itself as well as all &kde; applications. In general &kde;
stores all its files in a directory tree with a fixed structure.
By default &kde; uses two directory trees:One at the system level (for example /opt/trinity).One at the user level in the user's home directory
(usually
~/.kde)As a system administrator you can create additional trees. Such
additional trees can be used for profiles&SuSE; &Linux; for example uses:$HOME/.kde/opt/trinity. (This is
&SuSE;-specific; other distributions may use
/usr or /usr/trinity)/etc/opt/trinity. (This was added by
&SuSE;).If you have the KIOSK Admin tool v0.7 or later installed you can
check which directory trees are used with the following command:
kiosktool-tdedirs&kde; and &kde; applications look up files by scanning all the
&kde; directory trees. The directory trees are checked in order of
precedence. When a file is present in multiple directory trees, the
file from the last tree takes precedence. Normally, the tree
located in the user's home directory has the highest precedence. This
is also the directory tree to which changes are written.For information about the text/plain &MIME; type
the following files are searched:$HOME/.kde/share/mimelnk/text/plain.desktop/opt/trinity/share/mimelnk/text/plain.desktop/etc/opt/trinity/share/mimelnk/text/plain.desktopIf a user makes a change, the change is written to $HOME/.kde/share/mimelnk/text/plain.desktopFor configuration files the story is slightly different. If
there are multiple configuration files found in the directory trees
with the same name, their content is combined. The precedence order of
the directory trees plays a role here. When two files define the same
configuration key, the file with the highest precedence determines
which value is used for the key.
For example, if the following two files exist, with these contents:$HOME/.kde/share/config/foobar
Color=red
Shape=circle
/etc/opt/trinity/share/config/foobar
Color=blue
Position=10,10
The files will be merged to result in:
Color=red
Shape=circle
Position=10,10
Specifying DirectoriesEnvironment VariableExample Setting(s)CommentTDEHOME~/.kdeTDEROOTHOME/root/.kdeDifferent variable to prevent
root writing to $TDEHOME of the user after running
su.TDEDIR/opt/trinity, /usr, /usr/trinityVendor dependent. Used by &kde; 2. If not set, falls back to
compiled-in default.TDEDIRS/opt/trinity, /usr, /usr/trinityNew in &kde;3. Can list multiple locations separated by a
colon. If not set, falls back to $TDEDIRDon't need to be set, defaults work just fine.Running &kde;2 next to &kde;3? Point $TDEDIR to
&kde; 2 and $TDEDIRS to &kde; 3.A staff member at a university could have the following
settings:
TDEHOME='~/.trinity'
TDEROOTHOME='/root/.trinity'
TDEDIRS='/opt/kde_staff:/opt/trinity'
User ProfilesIn the previous example /opt/kde_staff contained additional settings
and applications for staff members. User Profiles allow you
to add this directory only for certain users and not for others. Add the
following to /etc/kderc:
[Directories-staff]
prefixes=/opt/kde_staff
This creates a profile named staff that adds the
/opt/kde_staff directory
tree. (Note that &SuSE; &Linux; uses
/etc/trinityrc instead of
/etc/kderc. Now that we have a named profile it
can be assigned to users.To map profiles to users a mapping file needs to be specified in
/etc/kderc:
[Directories]
userProfileMapFile=/etc/kde-user-profile
It is now possible to assign a profile based on either the user name
or based on the &UNIX; group the user is part of.To assign the staff profile to all users that are a member of the
&UNIX; group staff_members add the following to
/etc/kde-user-profile:
[General]
groups=staff_members
[Groups]
staff_members=staff
It is also possible to assign a profile to a single user:
[Users]
bastian=staff
Directory Layout RevisitedEach directory tree used by &kde; has a fixed directory structure.
Directories that are not relevant for a certain tree, or simply not used can
be left out though. For example, directories used for temporary files are
usually only found under $TDEHOME but not in any other
directory tree.Architecture-specific DirectoriesArchitecture (OS and CPU type) specific directories:binUsed for &kde; executables.libUsed for &kde; libraries.lib/trinityThis directory contains components, plugins, and other
runtime loadable objects for use by &kde; 3.x
applications.Shared DirectoriesShared: Not architecture specific, can be shared between different
archs.share/applnk.desktop files for
&kde;-menu (old)share/applications.desktop files for
&kde;-menu (since &kde; 3.2)share/appsContains application-specific data files. Each
application has a sub-directory here for storing additional data
files.share/configConfiguration files. Configuration files are normally
named after the application they belong to plus the letters
rc. A special case is kdeglobals.
This file is read by all &kde; applications.share/config/sessionThis directory is used by session management and is
normally only available under $TDEHOME. At the end of a
session &kde; applications store their state here. The file names
consist of the name of the application followed by a number. The
session manager ksmserver stores references to
these numbers when saving a session in
ksmserverrc.share/doc/HTMLThis directory contains documentation for &kde;
applications. Documentation is categorized by language and the
application it belongs to. Normally at least two files can be found in
a directory: index.docbook, which contains the
documentation in the unformatted DocBook format, and
index.cache.bz2, which contains the same
documentation formatted as bzip2-compressed
&HTML;. The &HTML; version is used by &khelpcenter;. If the &HTML;
version is missing, &khelpcenter; will regenerate it from the DocBook
version but this is a time-consuming process.share/iconsUnder this directory icons are stored. Icons are
categorized by theme, dimension and usage category.share/mimelnkIn this directory,.desktop files that describe &MIME; types
are stored. &kde; uses &MIME; types to identify the type of a
file.share/servicesThis directory contains .desktop files that describe services. Services
are like applications but are usually launched by other applications instead
of the user. Services do not appear in the &kde; menu.share/servicetypesThis directory contains .desktop files that describe
servicetypes. A servicetype usually represents a certain programming
interface. Applications and Services include in their >.desktop files the servicetypes that they
provide.share/soundsThis directory contains sound files.share/templatesThis directory contains templates for creating files
of various types. A template consists of a .desktop file that describes the file and
that includes a reference to a file in the .source sub-directory. The templates in
this directory appear in the Create New menu
available on the desktop and in the file browser. When a user selects
a template from the menu its source file is copied.share/wallpapersThis directory contains images that can be used as
background pictureHost-specific DirectoriesThere are three host-specific directories that are usually
symlinked to other locations. If the directories do not already exist,
the following symlinks and directories will be created using the
lnusertemp utility:$TDEHOME/socket-$HOSTNAMEUsually /tmp/tdesocket-$USER/, this
is used for various &UNIX; sockets.$TDEHOME/tmp-$HOSTNAMEUsually /tmp/kde-$USER/, this is used for temporary files.$TDEHOME/cache-$HOSTNAMEUsually /var/tmp/kdecache-$USER/,
this is used for cached files.Since both /tmp and
/var/tmp are world writable,
there is a possibility that one of the above directories already
exists but is owned by another user. In that case the
lnusertemp utility will create a new directory with
an alternative name and link to that instead.Configuration Files&kde; uses a simple
text-based file format for all its configuration files. It consists of
key-value pairs that are placed in groups. All &kde; configuration
files use UTF-8 encoding for text outside the
ASCII range.The start of a group is indicated by a group name that is placed
in square brackets. All the key-value entries that follow belong to
the group. The group ends when either another group starts or when the
end of the file is reached. Entries at the top of the
file that are not preceded by a group name belong to the default
group.The following example shows a configuration
file that consists of two groups. The first group contains the keys
LargeCursor and SingleClick, the
second group contains the keys Show hidden files
and Sort by:
[KDE]
LargeCursor=false
SingleClick=true
[KFileDialog Settings]
Show hidden files=false
Sort by=Name
Entries in a group consist of a key and value separated by an equals
sign. The key can contain spaces and may be followed by options placed in
square brackets. The part after the equals sign is the value of the
entry. Any white space surrounding the equals sign is ignored, as is any
trailing white space. Put more concisely, the format is:entry=valueIf a value is supposed to include a space at the begin or end
then this can be achieved by using a backslash followed by an
s.There are several other backslash codes; here is a complete
list:
\s can be used as space\t can be used to include a tab\r for a carriage return character\n for a linefeed character (new line)\\ to include the backslash itselfIn the following example the value of the
Caption entry starts with two spaces while the
Description entry contains three lines of
text. Linefeeds in backslash notation are used to separate the
different lines.
[Preview Image]
Caption=\s My Caption
Description=This is\na very long\ndescription.
Empty lines in configuration files are ignored, as are lines that
start with a hash mark (#). The hash mark can be used to add
comments to configuration files. It should be noted that when a &kde;
application updates a configuration file the comments are
not preserved.There can be multiple configuration files with the same name in the
share/config sub-directory of the
various &kde; directory trees. In this case the information of all these
configuration files is combined on a key-by-key basis. If the same key
within a certain group is defined in more than one place, the key value read
from the directory tree with the highest precedence will be used.
Configuration files under $TDEHOME always have the highest
precedence. If a key in a certain group is defined multiple times in a
single file, the value of the last entry is used.If $HOME/.kde/share/config/foobar
contains:
[MyGroup]
Color=red
Shape=circle
and /etc/opt/trinity/share/config/foobar contains
[MyGroup]
Color=blue
Position=10,10
the result will be:
[MyGroup]
Color=red
Shape=circle
Position=10,10
If
$HOME/.kde/share/config/foobar
contains
[MyGroup]
Color=red
Shape=circle
[MyGroup]
Color=green
and /opt/kde_staff/share/config/foobar contains
[MyGroup]
Color=purple
Position=20,20
and /etc/opt/trinity/share/config/foobar contains
[MyGroup]
Color=blue
Position=10,10
the result will be:
[MyGroup]
Color=green
Shape=circle
Position=20,20
To prevent users being able to override default settings,
settings can be marked immutable. Settings can be made immutable
individually, per group or per file. An individual entry can be locked
down by adding [$i] behind the key, ⪚:
Color[$i]=blue
A group of entries can be locked down by placing
[$i] behind the group name, ⪚:
[MyGroup][$i]
To lock down the entire file, start the file with
[$i] on a single line, &ie;:
[$i]
If
$HOME/.kde/share/config/foobar
contains:
[MyGroup]
Color=red
Shape=circle
and /etc/opt/trinity/share/config/foobar contains:
[MyGroup][$i]
Color=blue
Position=10,10
the result will be:
[MyGroup]
Color=blue
Position=10,10
If
$HOME/.kde/share/config/foobar
contains:
[MyGroup]
Color=red
Shape=circle
and /opt/kde_staff/share/config/foobar contains
[MyGroup]
Color=purple
Shape=rectangle
and /etc/opt/trinity/share/config/foobar contains
[MyGroup][$i]
Color=blue
Position=10,10
the result will be
[MyGroup]
Color=purple
Shape=rectangle
Position=10,10
So-called Shell Expansion can be used to provide more
dynamic default values. With shell expansion the value of a configuration
key can be constructed from the value of an environment variable or from the
output of a shell command. To enable shell expansion for a configuration
entry, the key must be followed by [$e]. Normally the
expanded form is written into the user's configuration file after first use.
To prevent that, it is recommend to lock the configuration entry down by
using [$ie]. The user can't change it then of course.In the following example the value for the Host
entry is determined by the output of the hostname
program. This setting is also locked down to ensure that the value is always
determined dynamically.The value for the Email entry is determined by
filling in the values of the $USER and $HOST
environment variables. When joe is
logged in on joes_host this will
result in a value equal to joe@joes_host. The setting is
not locked down.
[Mail Settings]
Host[$ie]=$(hostname)
Email[$e]=${USER}@${HOST}
Most configuration entries can be indexed with a language code. In
this case, the language that the user has selected for use on the desktop is
used to look up the key value. If the default language (American English)
has been selected or if there is no index that corresponds to the selected
language, the key entry without index is used.In the following example the value of the Caption
entry depends on the language. If the user has selected French as language
(language code fr) the value of the entry will be
Ma Légende. In all other cases the value My
Caption will be used.
[Preview Image]
Caption=My Caption
Caption[fr]=Ma Légende
In this example the value of the Caption entry
depends on the language. If the user has selected French as language
(language code fr) the value of the entry will be
Ma Légende. In all other cases the value My
Caption will be used.
[Preview Image]
Caption=My Caption
Caption[fr]=Ma Légende
In general the entries that can appear in a configuration file are not
documented. With &kde; 3.2 a start has been made to change this. In
$TDEDIR/share/config.kcfg, files
can be found that provide a formal description of the possible entries in a
configuration file. These are used by the new &kde; Configuration Editor
when available.Here is an example &XML; configuration file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE kcfg SYSTEM "http://www.kde.org/standards/kcfg/1.0/kcfg.dtd">
<kcfg>
<kcfgfile name="korganizerrc"/>
<group name="General">
<entry type="Bool" key="Auto Save">
<label>Enable automatic saving of calendar</label>
<default>true</default>
</entry>
<entry type="Int" key="Auto Save Interval">
<default>10</default>
</entry>
</group>
</kcfg>
It has the same effect as:
[General]
Auto Save=false
Auto Save Interval=25
&kde; Startup Sequence&tdm;Always runs as root! Uses
$TDEDIR/share/config/tdmrc and
/etc/X11/xdm/Xservers. The latter contains entries
like:
:0 local /usr/X11R6/bin/X :0 vt07
Relevant startup files are also:
[X-*-Core] section in tdmrc
Setup - /etc/X11/xdm/Xsetup
User enters username & password
Startup - /etc/X11/xdm/Xstartup - prepare as root
Session - /etc/X11/xdm/Xsession - starts session as user
= For a KDE session: kde or starttde
= If present ~/.xsession or ~/.xinitrc
Reset - /etc/X11/xdm/Xreset - after session finished
The &kde; Startup Script: starttdeThe &kde; startup sequence starts with the
starttde script. In most cases this script gets called
from the display manager (&tdm;) once the user has been authenticated. Their
are two very important lines in the starttde
script:
LD_BIND_NOW=true tdeinit +kcminit +knotify and kwrapper
ksmserver $KDEWM
The first line starts the tdeinit master process.
The tdeinit master process is used to start all other
&kde; processes. It show up in the output of ps
as tdeinit:
Running.... The arguments after tdeinit
are the names of additional processes to be started. The +
indicates that tdeinit needs to wait till the process has
finished. tdeinit also starts
dcopserver, klauncher and
kded.The second of the two lines asks tdeinit to start
the ksmserver session manager process. The session
manager determines the lifetime of the session. When this process exits, the
user is logged out.Background ProcessesAll &kde; background services are user-specific: unlike system daemons
they are not shared between users. As well as being unique per user they are
also unique per X-server display. The processes are:dcopserverDesktop communicationkdedGeneric service daemon.Triggers Sycoca database updates when
neededkcminitInitialization serviceSee for more information.klauncherProgram launch (this is not the
&Alt;F2dialog!)See for more information.knotifyUser notifications.See for more information.ksmserverSession managementSee for more information.tdeinittdeinit is used to start all other &kde;
programs. tdeinit can start normal binary program files
as well as tdeinit loadable modules
(KLMs). KLMs work just like binary
program files but can be started more efficiently. KLMs
live in $TDEDIR/lib/trinityThe drawback is that programs started this way appear as
tdeinit in the output of
top and ps. Use top
or ps
to see the actual program name:%ps
waba 23184 0.2 2.1 23428 11124 ? S 21:41 0:00 tdeinit: Running...
waba 23187 0.1 2.1 23200 11124 ? S 21:41 0:00 tdeinit: dcopserver --nosid
waba 23189 0.2 2.4 25136 12496 ? S 21:41 0:00 tdeinit: klauncher
waba 23192 0.7 2.8 25596 14772 ? S 21:41 0:00 tdeinit: kded
waba 23203 0.8 3.4 31516 17892 ? S 21:41 0:00 tdeinit:
knotify
tdeinit: Running... indicates the
master tdeinit process. The other processes listed are
programs started as KLMs.When tdeinit starts for the first time it will
launch dcopserver, klauncher, and
kded, as well as any additional programs specified on its
command line in the starttde script, normally
kcminit and knotify.dcopserverdcopserver is a daemon which provides inter-process
communication (&DCOP;) facilities to all &kde; applications. The &DCOP;
facilities are accessible from the command shell via the
dcop command line tool. &DCOP; is essential for all &kde;
applications.Some related files:$HOME/.DCOPserver_$HOSTNAME_$DISPLAY⪚ .DCOPserver_linux__0. Controlled by $DCOPAUTHORITY/tmp/.ICE-unix/dcoppid-number⪚ dcop7634-1069677856. This is
the file that the DCOPserver file above points to.$HOME/.ICEauthorityAuthorization information controlled by
$ICEAUTHORITYkcminitkcminit executes initialization services during
startup. Initialization services are specified in the .desktop files of
applications or services via the X-KDE-Init line:
[Desktop Entry]
Encoding=UTF-8
Exec=kcmshell energy
Icon=energy_star
Type=Application
X-KDE-Library=energy
X-KDE-Init=energy
Initialization services are typically used for initializing
hardware based on user-specified settings.kcminit
can be used to show all
initialization services and kcminit
service can be used to
execute a single service explicitly. This can be useful when investigating
startup problems.klauncherklauncher is a daemon which is responsible for
service activation within &kde;. It operates in close connection with the
tdeinit master process to start new processes. &kde;
applications communicate with klauncher over &DCOP; in
order to start new applications or services.Best known from the error message:
KLauncher could not be reached via DCOP which
either indicates a serious problem with the dcopserver or
that klauncher crashed.klauncher can be restarted by restarting
tdeinit from a console window. Make sure that
$HOME, $DISPLAY and the various
$TDEDIR(S) are set correctly when doing so!knotifyThe primary task of knotify is to relay sound
notifications to the sound server, it also provides alternative notification
methods.KSMServerksmserver is &kde;'s session manager. On startup
the session manager launches auto-start applications and restores
applications from the previous session. The applications to auto-start are
indicated by .desktop files in the
$TDEDIR/share/autostart
directory. Whether or not to auto-start an application can be made
conditional upon some configuration entry determined by the
X-KDE-autostart-condition entry in the .desktop file.The ktip.desktop file for example
contains:
X-KDE-autostart-condition=ktiprc:TipOfDay:RunOnStart:true
This means that the ktiprc configuration
file is checked for a RunOnStart entry in the
[TipOfDay] section. If no such entry is found,
true is assumed, which means that
ktip is one of the applications that is
auto-started by default.Some of the applications auto-started by ksmserver
are:kdesktopThe &kde; desktop&kicker;The &kde; panelktipA tip of the day programkwritedA utility to receive system messages sent to the user&klipper;A clipboard utility that docks in the panelkalarmA utility that warns about upcoming events and appointmentskdesktop in its turn automatically starts
applications stored in $TDEHOME/Autostart. kdesktop
will automatically open any files stored in this directory including
documents, binary files or applications in the form of .desktop files.The &kde; session manager also restores one of the previous
sessions. A session contains a collection of applications as well as
application-specific information that reflects the state of the applications
at the time the session was saved. Sessions are stored in the
ksmserverrc configuration file which contains
references to application-specific state information. The
application-specific state information is saved in $TDEHOME/share/config/session.
The state information of &twin; contains the location of the application
windows of all the other applications in the session.
Environment variablesSome important environment variables used by &kde;:$TDEDIRHas to be set if
TDEDIRS is not set and has to point to the root of the
&kde; installation tree. Allows &kde; to find its data like icons,
menus and libraries.$TDEDIRSOverrides TDEDIR and allows you to specify
multiple directories where &kde; searches for its data. Useful if you want
or have to install some programs to a different prefix than the rest of
&kde;.$TDEHOMEIf
not set, &kde; uses ~/.kde as
the directory where personal data is stored.$TDEROOTHOMEIf
not set, &kde; uses ~root/.kde
as the directory for root's
personal data. Was introduced to prevent &kde; from accidently
overwriting user data with root permissions when the user runs a &kde;
program after switching with su to root.$KDEWMIf the
KDEWM environment variable has been set, then it will
be used as &kde;'s window manager within the
starttde script instead of &twin;.$KDE_LANGOverrides
the &kde; language configuration, ⪚ KDE_LANG=fr kprogram
& starts a program with French translation if the
necessary files are installed.$TDE_MULTIHEADSet
this variable to true to indicate that &kde; is running
on a multi-head system.$KDE_FORK_SLAVES(Since &kde; 3.2.3) Set this variable to spawn
KIO-slaves directly from the application process
itself. By default KIO-slaves are spawned using
klauncher/tdeinit. This option is
useful if the KIO-slave should run in the same
environment as the application. This can be the case with
Clearcase.$KDE_HOME_READONLYSet this variable to indicate that your home directory is
mounted as read-only.$KDE_NO_IPV6
(Since &kde; 3.2.3) - Set this variable to disable IPv6
support and IPv6 DNS
lookups.$KDE_IS_PRELINKED
(Since &kde; 3.2) - Set this variable to indicate that you have prelinked
your &kde; binaries and libraries. This will turn off
tdeinit.$KDE_UTF8_FILENAMESIf
this environment variable is set, &kde; assumes all filenames are in
UTF-8 encoding regardless of the current C
locale.$TDE_FULL_SESSION
(Since &kde; 3.2) Automatically set to true by &kde; startup, it is used
by ⪚ &konqueror; to know if it should consider remaining in memory
for future re-use when being closed. If not set, &konqueror; will exit
after being closed (⪚ &tdesu; does that, it's also useful for
debugging).$KDESYCOCAAllows
you to specify the path and the name of the generated &kde; system
configuration cache file.$KDETMPAllows
to specify another path than /tmp where &kde; stores its temporary
files.$KDEVARTMPAllows
to specify another path than /var/tmp where &kde; stores its variable
files.$XDG_DATA_HOME
(Since &kde; 3.2) Defines the base directory relative to which user-specific
data files should be stored. Default is $HOME/.local/share$XDG_DATA_DIRS
(Since &kde; 3.2) Defines the preference-ordered set of base directories to
search for data files in addition to the $XDG_DATA_HOME base
directory. Default is
/usr/local/share/:/usr/share/&kde; adds locations from $TDEDIRS and profiles
as well. Used for .desktop and
.directory menu files. .desktop files under $XDG_DATA_DIRS/applications.
.directory files under
$XDG_DATA_DIRS/desktop-directories
$XDG_CONFIG_HOME
(&kde; 3.2) - Defines the base directory relative to which user
specific configuration files should be stored. Default is
$HOME/.config.$XDG_CONFIG_DIRS
(&kde; 3.2) - Defines the preference-ordered set of base directories
to search for configuration files in addition to the $XDG_CONFIG_HOME
base directory. The default is /etc/xdg &kde; adds locations from
$TDEDIRS and profiles as well. Used by .menu descriptions in
$XDG_CONFIG_DIRS/menus.
The tdeinit Mysterytdeinit is used to start all other &kde;
programs. tdeinit can start normal binary program f iles
as well as tdeinit loadable modules
(KLMs). KLMs work just like binary
program files but can be started more efficiently. KLMs
live in $TDEDIR/lib/trinityThe drawback is that programs started this way appear as
tdeinit in the
output of top and ps. Use
top or ps
to see the actual program name:%ps aux | grep bastian
bastian 26061 0.0 2.2 24284 11492 ? S 21:27 0:00 tdeinit: Running...
bastian 26064 0.0 2.2 24036 11524 ? S 21:27 0:00 tdeinit: dcopserver
bastian 26066 0.1 2.5 26056 12988 ? S 21:27 0:00 tdeinit: klauncher
bastian 26069 0.4 3.2 27356 16744 ? S 21:27 0:00 tdeinit: kded
bastian 26161 0.2 2.7 25344 14096 ? S 21:27 0:00 tdeinit: ksmserver
bastian 26179 1.1 3.4 29716 17812 ? S 21:27 0:00 tdeinit: kicker
bastian 26192 0.4 3.0 26776 15452 ? S 21:27 0:00 tdeinit: klipper
bastian 26195 1.0 3.5 29200 18368 ? S 21:27 0:00 tdeinit: kdesktop
As you might have noticed, this has another side effect, making it
difficult to kill a process that is causing trouble:%killall kdesktopkdesktop: no process killedYou might be tempted to try killall
tdeinit, but killing all tdeinit processes will have
the effect of shutting down all of &kde;. In effect, total
destruction!There are two simple solutions to this:%kdekillall kdesktop
or good old
%kill 26195kdekillall is part of the &kde; SDK
package.Customizing &kde;Desktop Icons&kde; uses several types of icons:DocumentsLinks to Websites (using .desktop file)Links to Applications (using .desktop file)Devices - Disks, Partitions & Peripherals:
Explicit using .desktop fileAutomatic via devices:// io-slaveVendor-specific (⪚ &SuSE;'s My Computer)Websites
Links to Websites using .desktop
file: Create
NewFileLink to
Location (URL). Change Icon using
Properties dialogs. The resulting .desktop file:
[Desktop Entry]
Encoding=UTF-8
Icon=/opt/trinity/share/apps/kdesktop/pics/ksslogo.png
Type=Link
URL=http://www.kde.org/
ApplicationsLinks to Applications using .desktop file: Create
NewFileLink to
Application. You must provide details
yourself. Drag from &kde; Menu: Either copy or link (creates symlink),
much easier
[Desktop Entry]
Encoding=UTF-8
GenericName=IRC Client
GenericName[af]=Irc Kliët
GenericName[de]=IRC Programm
...
GenericName[zu]=Umthengi we IRC
SwallowExec=
Name=KSirc
Name[af]=Ksirc
Name[de]=KSirc
...
Boiler plateTranslated generic description, not used on desktopLegacy, can be removedTranslated name as it appears on desktopDesktop Icons
...
Name[zu]=Ksirc
MimeType=
Exec=ksirc %i %m
Icon=ksirc
TerminalOptions=
Path=
Type=Application
Terminal=0
X-KDE-StartupNotify=true
X-DCOP-ServiceType=Multi
Categories=Qt;KDE;NetworkSupported &MIME; types, not used on
desktopThe command line to executeThe icon, from icon theme or full pathOnly used if terminal is
neededWorking directory for commandMore boiler plateUse true if terminal is needed,
text applicationShow bouncy cursor,
disable if it doesn't work.Has app started ok?
Remove if it doesn't workCategories for &kde; Menu, not
used on desktopThe Exec option in .desktop filesFollowing the command, you can have several place holders which will
be replaced with the actual values when the actual program is run:
%fA single file name; used when dropping
file on icon, or with file associations.%FA list of files; use for applications that can
open several local files at once.%uA single &URL;: if the app can
handle ⪚ &FTP; or &HTTP; &URL;s itself, otherwise &kde;.%UA list of
&URL;s; will download the file first and pass a local file to the app
(!!)%dThe folder of the file to open; useful if app needs to
have file in current working directory.%DA list of folders, not very practical.%iThe icon; option; &kde; app
will use icon from Icon= line in taskbar.%mThe mini-icon; legacy.%cThe caption; option; &kde;
app will use name from Name= line in
taskbar.Examples:
Exec lineCommand executedksirc %iksirc --icon ksirccd %d; kedit $(basename %f)cd /tmp; kedit file.txtDevices
Links to Devices using .desktop file:
o Create New -> Device
Where to DefineMany places to define Desktop Icons:
~/Desktop:
copied from /etc/skel/Desktop$TDEDIR/apps/kdesktop/Desktop
(merged)$TDEDIR/apps/kdesktop/DesktopLinks
(copied)Device Icons (dynamically
merged)Distribution Specific SUSE Linux copies certain icons
in starttde.theme from /opt/trinity/share/config/SuSE/default/&kde; MenuHow it WorksIn &kde; 3.2 a common menu format is introduced at
http://freedesktop.org/Standards/menu-spec/Before &kde; 3.2:
Directory structure under share/applnkDirectory structure represents menu
structureEach .desktop file
represents a single applicationIt was difficult to rearrange the structure in &kde; 3.2 so the
new menu format:
Defines structure in a single .menu fileIs based on categoriesis shared between GNOME and &kde;Supports applnk style menus as wellExample from kde-applications.menu:
<Menu>
<Name>Office</Name>
<Directory>suse-office.directory</Directory>
<Include>
<Filename>Acrobat Reader.desktop</Filename>
<Filename>kde-kpresenter.desktop</Filename>
<Filename>kde-kword.desktop</Filename>
</Include>
<Menu>
Menu entry with 3 applications:
/usr/share/applications/Acrobat
Reader.desktop/opt/trinity/share/applications/kde/kpresenter.desktop/opt/trinity/share/applications/kde/kword.desktopStored Where?.menu files describing the
menu structure. The files are stored in $TDEDIR/etc/xdg/menus and
/etc/xdg/menus. These store the
system-wide menu structure and are controlled by
$XDG_CONFIG_DIRS. $HOME/.config/menus stores
user-specific changes to the menu structure and is controlled by
$XDG_CONFIG_HOME. For more information, see http://www.freedesktop.org/Standards/basedir-spec..desktop files describe the
applications and are stored in: $TDEDIR/share/applications,
/usr/share/applications,
/usr/local/share/applications. These are
the system-wide application .desktop files which are controlled by
$XDG_DATA_DIRS.$HOME/.local/applications
contains user-specific .desktop
files and user-specific changes. It is controlled by
$XDG_DATA_HOME. For more information, see http://www.freedesktop.org/Standards/basedir-spec.directory files describing
the sub-menus are stored in: $TDEDIR/share/desktop-directories,
/usr/share/desktop-directories, /usr/local/share/desktop-directories.
These are the system-wide menu .directory files, controlled by
$XDG_DATA_DIRS. The user-specific changes are stored in $HOME/.local/desktop-directories.
These are controlled by $XDG_DATA_HOME. For more
information, see http://www.freedesktop.org/Standards/basedir-specExample from kde-applications.menu:
<Menu>
<Name>Art</Name>
<Directory>suse-edutainment-art.directory</Directory>
<Include>
<Category>X-SuSE-Art</Category>
</Include>
</Menu>
Art is the internal name for this
menu. suse-edutainment-art.directory defines the
name and icon for this menu, and the menu includes all applications
that have X-SuSE-Art listed as a category, ⪚:
Categories=Qt;KDE;Education;X-SuSE-Art
suse-edutainment-art.directory defines the
name and icon for this menu:
[Desktop Entry]
Name=Art and Culture
Icon=kcmsystem
Common PitfallsApplications not in the menu do
not exist with regard to other applications or
file associations: If you remove an application from the menu, &kde; assumes you don't want to use it.When applications are unwanted in the menu, either place them in
.hidden menu or a dedicated menu with
NoDisplay=true
in the .directory fileEssential Menus$TDEDIR/etc/xdg/menus/applications-merged/
contains kde-essential.menu which includes some
essential menus that are normally not shown in the &kde; menu itself:
Control Center has a hidden Settings menu whose
contents are defined by kde-settings.menu and
whose icon and name are defined by kde-settings.directoryInfo Center has a hidden Information menu whose
contents are defined by kde-information.menu and
whose icon and name are defined by kde-information.directory.Screensavers contains a hidden System/Screensavers menu,
whose contents are defined by
kde-screensavers.menu and whose icon and name
are defined by
kde-system-screensavers.directory.
$TDEDIR/share/desktop-directories/kde-system-screensavers.directory
contains:
NoDisplay=true
Old-Style Menus&kde; continues to support old-style menus that are defined by
the directory structures in $TDEDIR/share/applnk
(system wide) and $HOME/.kde/share/applnk
(user specific). This is observed unless the .desktop file has a Categories= line. In that case the categories determine the location in the menu.KSycocaKSycoca caches menu structure and
information about all available applications. You can rebuild the
database with
kbuildsycoca. The database
which is built lives in /var/tmp/kdecache-${USER}/ksycoca.
It is automatically updated by KDED,
checked during &kde; login, and KDED
watches for changes while logged in.To disable watching for changes (since it may hurt over NFS) add
the following to kdedrc:
[General]
CheckSycoca=false
To force regeneration, run touch $TDEDIR/share/services/update_ksycoca.&kmenuedit;&kmenuedit; is aimed at a single user setup. Changes to menu
structure are saved to
~/.config/menus/applications-kmenuedit.menu,
changes to applications are saved in ~/.local/share/applications/ and changes
to sub-menus (icon, name) are saved in ~/.local/share/desktop-directories/. The
KIOSK Admin Tool uses &kmenuedit; and copies the above changes to
profile- or system-wide locations.
&kde; PanelThe &kde; panel is also known as &kicker;. It is modular and
consists of the following components:
AppletsApplication buttonsSpecial ButtonsBy default, the panel contains the following applets:
Pager - shows the virtual desktopsTaskbarSystem TrayClock
and the following special buttons:
&kde; menuDesktop ButtonVarious application buttons are also added, space permitting:
Home ButtonBrowser ButtonKMail ButtonFile AssociationsFile associations associate a file type with an application or
applications. The type of a file is established by determining its
&MIME; type. &MIME; types known by &kde; are stored in $TDEDIR/share/mimelnk and
each application's .desktop file
contains a list of &MIME; types supported by that application.kview.desktop:
MimeType=image/gif;image/x-xpm;image/x-xbm;image/jpeg;
image/x-bmp;image/png;image/x-ico;image/x-portable-bitmap;
image/x-portable-pixmap;image/x-portable-greymap;
image/tiff;image/jp2
kuickshow.desktop:
MimeType=image/gif;image/x-xpm;image/x-xbm;image/jpeg;
image/png;image/tiff;image/x-bmp;image/x-psd;image/x-eim;
image/x-portable-bitmap;image/x-portable-pixmap;
image/x-portable-greymap
Both can open image/gif Which one is used to open a .gif file?The application with highest
preference!. kview.desktop contains
InitialPreference=3
whereas kuickshow.desktop contains
InitialPreference=6
Therefore, &kuickshow; will be used to open .gif files.
How can we make &kview; default?A user can change file association in the
&kcontrolcenter;. These changes are stored in
$HOME/.kde/share/config/profilerc.
To use the same settings for multiple users, store these settings in
user profile directory or the global &kde; config directory to use as
default for multiple users.Locking Down &kde;How It Works - The Basics&kde;'s lock down features are centered around the following
options:Make
configuration options immutableRestriction of specific
actionsRestrict access to certain
&URL;sRestrict access to
certain configuration modulesImmutable Configuration OptionsLocking Down &kde;Immutable options allow system administrator to provide default
settings that can not be changed by the user.Pre-existing configuration options of the user will be ignored once a
configuration option is made immutable.Options can be controlled either on a per entry basis, per group of
entries or on a file by file basis.If a file or group is immutable, all configuration options for that
file or group are immutable, even those options for which the system
administrator has no default provided.The support in applications for immutable options may vary from
application to application. Although the user will not be able to make
permanent changes to immutable configuration options, the user may still be
presented with an user interface option to make such change.Action Restrictions&kde; applications are built around the action-concept. Actions can be
activated in various ways, typically via the menu-bar, one of the toolbars
or a keyboard shortcut. Save Document is an example of an
action. If you know the internal action name it is possible to restrict an
action. When an action is restricted it will no longer appear in the
menu-bar or toolbar. The internal name for the Save
Document action is . The lock
down framework also provides a set of more abstract restrictions which can
be used to disable functionality not covered by a single action. An example
is the restriction which disables all
functionality that would offer the user access to a &UNIX; shell.Restrict User Access to ShellsIn order to prevent the user access to a command shell we can restrict
the action by adding the following to
kdeglobals:
[KDE Action Restrictions]
shell_access=falseSince this affects the &kde; menu and the available applications, we
must force an update of the sycoca database:touch$TDEDIR/share/services/update_ksycocaNow re-login to &kde; and check the following points:The &kmenu;In &konqueror;,
ToolsOpen
TerminalThe &Alt;F2 run
commandFull documentation about available actions can be found on http://www.kde.org/areas/sysadmin/.A few of the more interesting actions are listed below:The Configure option form the
Settings menuThe Report Bug option from the
Help menu.&RMB; mouse button menu on the desktop.&RMB; mouse button menu on the panel.Hide all actions or applications that require root access.Hides all actions or applications that provide shell
access.Disables the option to select the printing system
(backend).Whether the user will be able to lock the
screenWhether the user may start a second X session (see also
&tdm;)Whether OpenGL screensavers are allowed to be
used.Permit screensavers that do not hide the entire
screen&URL; RestrictionsThere are three types of restrictions that can be applied to
&URL;s:listTo control whether a directory listing is
allowed.openTo control whether certain &URL;s can be
openedRedirectTo control whether one &URL; can open another &URL;, either
automatically or via a hyperlink.Rules are checked in the order in which they are defined. The last
rule that is applicable to a &URL; defines whether the &URL; may be
accessed.The following rules disable opening http and https &URL;s outside
.ourcompany.com:[KDE URL Restrictions]
rule_count=2
rule_1=open,,,,http,,,false
rule_2=open,,,,http,*.ourcompany.com,,trueThe first four commas skip over the selection criteria with respect to
the originating &URL;. This part is only needed with redirect type
rules. forbids the
opening of any http or https &URL; allows the
opening of any http and https &URL; in the .ourcompany.com domain. Note the wildcard
* is only allowed at the start of a domain.The following rules makes that the user can no longer browse
directories on the local file system that are outside his
$HOME directory:[KDE URL Restrictions]
rule_count=2
rule_1=list,,,,file,,,false
rule_2=list,,,,file,,$HOME,true forbids the
listing of any local directory allows listing
directories under the users own $HOME
directory.$HOME and $TMP are special values to
indicate the users home directory and the &kde; temporary directory of the
user, ⪚ /tmp/kde-bastianThe following rules makes that the user can no longer open local files
that are outside his $HOME directory:[KDE URL Restrictions]
rule_count=3
rule_1=open,,,,file,,,false
rule_2=open,,,,file,,$HOME,true
rule_3=open,,,,file,,$TMP,true forbids the
opening of any local file allows opening
files under the users own $HOME directory. allows opening
files in the &kde; temporary directory of the user. This is needed by
certain &kde; applications that first download a file or document to the
temporary directory and then open it in an application.The redirection option controls whether documents from a certain
location can refer, either automatically or manually via a hyperlink, to a
certain other location. A set of default rules is present as a general
security measure. For example documents located on the Internet may not
refer to locally stored documents.For example, if we want to give the intranet-server www.mycompany.com the possibility to refer
to local files we could add the following rule:[KDE URL Restrictions]
rule_count=1
rule_1=redirect,http,www.mycompany.com,,file,,,trueInstead of listing a protocol by name, it is also possible to specify
a whole group of protocols. For that the following groups have been
defined::localProtocols that access locally stored information, examples
are file:/, man:/, fonts:/, floppy:/:internetCommon internet protocols such as http and
ftpInformation about protocols is stored in *.protocol files stored in
$TDEDIR/share/services.The = entry defines the group a protocol is part
of:
grep$TDEDIR/share/services/*.protocolGeneral rules:The :local protocols may refer to any other
protocolIt's always allowed to refer to an :internet
protocolNot all protocols are part of a group, fish:/ for
example.Configuration Modules&kde; has configuration modules to configure various aspects of the
&kde; environment. Configuration modules appear in the Control Center, in the
Configuration dialog of an application or in both.The proxy configuration module appears in the Control Center but also
as part of the Configure Konqueror dialog in
&konqueror;Individual configuration modules can be started with
kcmshellmoduleTo start the Proxy module use:kcmshellkde-proxy.desktopkcmshell proxyNot all applications use configuration modules, often the
configuration dialog is an integral part of the application
itself.All configuration modules are strictly speaking part of the &kde;
menu.The modules that are visible in the Control Center normally
have a .desktop file in $TDEDIR/share/applications/kde
and are sorted under the hidden Settings-Modules menu by
the kde-settings.menu, included from
kde-essential.menukbuildsycoca 2> /dev/null | grep Settings-ModulesApplication specific modules normally have a .desktop file under
$TDEDIR/share/applnk/.hidden which
corresponds to the hidden .hidden menu, included as a result of
<KDELegacyDirs/>kbuildsycoca 2> /dev/null | grep .hiddenIn &kde; 3.3 it is possible to edit the Control Center with
kcontroledit.
kcontroledit works just like
kmenuedit, changes for current user only. Use
kiosktool to make changes for
everyone.Individual configuration modules can be disables by adding the
following to kdeglobals:[TDE Control Module Restrictions]
module-id=falseFor example, to disable the proxy module use[TDE Control Module Restrictions]
kde-proxy.desktop=falseCheck the Control Center and the Configure
Konqueror dialog if the proxy configuration is still
there.The Lazy AdminRemote Desktop SharingRemote desktop sharing allows remote users to view and optionally
control the desktop of the current user. The remote user needs to be sent
an invitation, and it is possible to create a password protected standing
invitation. This is ideal for tech support teams or administrators to gain
access to users desktops in order to troubleshoot or remedy a problem or
guide a user through a procedure.Remote desktop sharing involves two applications: &krfb; (&kde; remote
frame buffer, a VNC server) and &krdc; (&kde; remote desktop connection; a
VNC client.)&krfb; can be used by any user to create and manage invitations.
Invitations create a one time password that allows the recipient to connect
to your desktop. By default it is valid for only one successful connection,
and expires after one hour if not used.Incoming connections are handled by the kinetd kded module. You can
use the command dcop kded kinetd
services to see if it is running. &krfb; waits for connections
on port 5900 by default. When an incoming connection is made, a dialog will
appear to ask for confirmation by the current user.&kde; DIY - Building Your Own ToolsDCOP
Desktop COmmunication Protocol, DCOP, is a lightweight mechanism for inter-process communication.
DCOP allows the user to interact with programs that are currently running.
&kde; supplies two programs to utilitize DCOP:
dcop, a command-line program, and
kdcop, a GUI program.
A few notes about using dcop:
dcop [options] [application [object [function [arg1] [arg2] ... ] ] ]
Applications that can open more than one window at a time will be listed as
<application>-PID
All the arguments are case-sensitve. setFullScreen and setfullscreen are two different functions.
The regular expression token * can be used in the application and object arguments.
% dcop
konqueror-16006
konsole-8954
Some example commands and their output are below:
% dcop
konsole-8954
One &konsole; is running with a PID of 8954.% dcop
KBookmarkManager-.../share/apps/kfile/bookmarks.xml
KBookmarkManager-.../share/apps/konqueror/bookmarks.xml
KBookmarkNotifier
KDebug
MainApplication-Interface
konsole (default)
konsole-mainwindow#1
ksycoca
session-1
session-2
session-3
session-4
Here you see that there are four sessions running.% dcop
QCStringList interfaces()
QCStringList functions()
int sessionCount()
QString currentSession()
QString newSession()
QString newSession(QString type)
QString sessionId(int position)
void activateSession(QString sessionId)
void nextSession()
void prevSession()
void moveSessionLeft()
void moveSessionRight()
bool fullScreen()
void setFullScreen(bool on)
ASYNC reparseConfiguration()
Here are the options for the main &konsole; program.
% dcop
QCStringList interfaces()
QCStringList functions()
bool closeSession()
bool sendSignal(int signal)
void clearHistory()
void renameSession(QString name)
QString sessionName()
int sessionPID()
QString schema()
void setSchema(QString schema)
QString encoding()
void setEncoding(QString encoding)
QString keytab()
void setKeytab(QString keyboard)
QSize size()
void setSize(QSize size)
Here are the options for the first session, session-1.% dcop trueThis sets &konsole; to full screen.
When there is more than one application/object, which one should you use?
Got a reference?
% echo
DCOPRef(konsole-7547,konsole)
% dcop
session-6
% dcopstart
konsole-9058
#!/bin/sh
konsole=$(dcopstart konsole-script)
session=$(dcop $konsole konsole currentSession)
dcop $konsole $session renameSession Local
session=$(dcop $konsole konsole newSession)
dcop $konsole $session renameSession Remote
session=$(dcop $konsole konsole newSession)
dcop $konsole $session renameSession Code
dcop $konsole $session sendSession 'cd /my/work/directory'
KDialog&kde; DIY - Building Your Own ToolsYou can use &kde; dialogs from your own scripts, to combine the power
of &UNIX; shell scripting with the ease of use of &kde;.kdialogkdialogThe KDialog part can be replaced via
optionkdialogSaves whether to show again in
$TDEHOME/share/config/myfile (by writing
into this file the following lines:[Notification Messages]
mykey=falseInstead of you can also use
and , as appropriate. For
instance, you might use kdialog or kdialog
.It is also possible to create message boxes that accept a yes or no
answer.kdialogecho$?Return ValueMeaning0Yes, OK, Continue1No2CancelMake sure to store the result in a variable if you do not use it
directly, the next command will fill $? with a new value You can use
here as well, it will remember the users choice
and returns it the next times without showing the dialog any more.Further variations are:like but with a different
iconWith Continue and
Cancel buttons.With Yes, No
and Cancel button. For example:kdialogkdialogThe result is printed to stdout, to put it in a variable you can use
name=$(kdialog --inputbox "Enter your name:"
"YourName"). The last argument is optional, it is used to
pre-fill the dialog.password=$(kdialog )The option does not work with
or There are two dialogs that let the user make a choice from a
list:Lets the user select a single item from a list.Lets the user select one or more items from a list.city=$(kdialog )$city will a, b, c or d.city=$(kdialog )Madrid and Paris will be pre-selected. The result with Madrid and
Paris selected will be "b""c".If you add the option, it will put
b and c each on a line
of its own, making the result easier to process.file=$(kdialog --getopenfilename $HOME)
file=$(kdialog --getopenfilename $HOME "*.png *.jpg|Image Files")
file=$(kdialog --getsavefilename $HOME/SaveMe.png)
file=$(kdialog --getexistingdirectory $HOME)
&groupware-with-kontact;