Next Previous Table of Contents

13. The KDE File System Standard

This chapter is a copy of the KDE-File System Standard as published on the KDE website at http://www.kde.org, written by Richard Moore rich@kde.org

KDE File System Standard

This file documents the directory structure that KDE and all KDE compliant applications should use. This is version 0.0.4 of the standard.

13.1 Introduction

The purpose of the KDE FSSTD is to ensure that all resources (icons, mimetypes etc.) needed for KDE applications are stored in a consistent directory structure. Following this structure allows applications to make use of tools such as the KIconLoader class and allows separation of the platform specific data needed by KDE from platform independent data (making installations on multiple architectures possible). In this document directory names have been suffixed with a `/` character. Where the word 'appname' appears in angle brackets <like this> it means that there should be an entry corresponding to every installed KDE application. The word 'lang' is used in the same way to indicate that there should be an entry for every supported language named according to the standard two letter language codes eg. 'fr' for French, 'de' for German etc.

13.2 Directory Layout

The KDE directory structure is as shown below, the top of the KDE installation tree is usually '/opt/kde' and can be found at run time by using the kdedir() method of KApplication (this replaces the KDEDIR environment variable the use of which is now deprecated). This document will refer to this directory as kdedir().

• kdedir()/
  • bin/
    • Application binaries
  • lib/
    • standard kde libraries (libkdecore etc.)
    • <appname>/
      • Application specific data that is platform dependent
  • include/
    • standard kde header files
  • parts/
  • cgi-bin/
    • CGI programs for kdehelp
  • share/
    • doc/
      • HTML/
        • default --> Link to kdedir()/share/doc/HTML/en
        • <lang>/
          • <appname>/
            • index.html
            • other application help files
    • config/
    • applnk/
      • System/
      • Utilities/
      • Applications/
      • Games/
      • kfind.kdelnk
      • khelp.kdelnk
      • khome.kdelnk
      • krefresh.kdelnk
    • mimelnk/
      • magic
      • text/
      • audio/
    • partlnk/
      • <partname>.kdelnk
    • icons/
      • Icons used in kdelnk files
      • <appname>.xpm
      • mini/
        • Mini Icons for kpanel
    • toolbar/
      • Standard toolbar pixmaps (eg. fileopen.xpm)
    • wallpapers/
      • Wallpapers used by kdisplay
    • apps/
      • <appname>/
        • toolbar/
          • Toolbar pixmaps
        • pics/
          • Other application pixmaps
        • application specific data (must be platform independent)
      • <libname>/
        • pics/
    • locale/
      • <lang>/
        • LC_MESSAGES/
          • <appname>.mo

13.3 What does this mean to application developers?

A standard KDE application will install files into several places in the above structure. The only required items are the application binary, the application kdelnk file, the application icon and the application help files - all others are optional. The most common things that are installed are:

Type of file                                      Location

Application binary (required)                     kdedir()/bin/
Application kdelnk file (required)                kdedir()/share/applnk/
Application icon (required)                       kdedir()/share/icons/<appname>.xpm
Application help files (required)                 kdedir()/share/doc/default/HTML/<appname>/<index>.html
Application toolbar pixmaps                       kdedir()/share/apps/<appname>/toolbar/
Application platform independent data             kdedir()/share/apps/<appname>/
Application platform specific data                kdedir()/lib/<appname>/

13.4 Application Documentation

I've suggested making putting at least a single page in

kdedir()/doc/default/HTML/<appname>/<appname>.html

a requirement for KDE compliance. The application is free to use the directory to store any help data it requires.

Applications that support more than one language would place the other languages inkdedir()/doc/<lang>/HTML/<appname>/<appname>.html with there being one 'lang' directory for each language code as usual. Arranging the files like this would allow links between the help files of two different applications that both support a given language.

I am not 100% happy with the solution I've suggested as it does not allow any way to fall back to the default language if a required translation is not available.

13.5 What does this mean to library developers?

• kdedir()/share/apps/<libname>/toolbar

• kdedir()/share/apps/<libname>/pics

Next Previous Table of Contents