Standard Resources (KDE3 Architecture) - Revision history

Blu256: Added a header

2022-04-21T16:37:04Z

Added a header

Blu256: Updated for TDE

2022-04-21T16:35:53Z

Updated for TDE

imported>Eliddell: Created page with "== Overview == KDE offers several ways to access the files that your application installed on your user's hard disc while making it transparent to you w..."

2014-05-27T20:40:42Z

Created page with "== Overview ==   KDE offers several ways to access the files that your application installed on your user's hard disc while making it transparent to you w..."

New page

== Overview == 


KDE offers several ways to access the files that your application
installed on your user's hard disc while making it transparent
to you where the data really are. To allow the user (or adminstrator
in most cases) to move files where he sees them fit best, KDE offers
a list of different resource types for which a different search path
is assigned to. You may have heard of the environment variable <tt>PATH</tt>
to lookup executables or <tt>MANPATH</tt> for looking up man pages. You wouldn't
expect ''man'' to lookup man pages in <tt>PATH</tt>.


Similiar to that concept KDE seperates search paths for different
things to make it simpler to add paths for a specific resource without
making a lookup for another resource unnecessary slower and without
requiring you to put everything into one directory.


The types of resources KDE offers are


* apps - applications menu (.desktop files)
* cgi - CGIs to run from khelpcenter

* config - configuration files
* data - where applications store data

* exe - executables installed privatly for KDE's use
* html - HTML documentation

* icon - application icons to appear in the window manager or the panel
* lib - libraries and to be dlopened modules

* locale - translation files for KLocale
* mime - mime types

* sound - application sounds
* toolbar - toolbar pictures
* wallpaper - wallpapers


For all of them exist also Makefile aliases that configures created by the development
tools provided for KDE (e.g. kdevelop) will know about.

== KStandardDirs == 


This is one of the most central classes in kdelibs as
it provides a basic service: it knows where the files
reside on the user's harddisk. And it's meant to be the
only one that knows - to make the real location as
transparent as possible to both the user and the applications.


For this it encapsulates all informations from the application
and applications always refer to a file with a resource type
(e.g. apps) and a filename (e.g. Home.desktop). In an ideal world
the application would make no assumption where this file is and
leaves it up to <tt>KStandardDirs::findResource("apps", "Home.desktop")</tt>
to apply this knowledge.


The main idea behind KStandardDirs is that there are several
toplevel prefixes where files are below. One of this prefixes is
the one where the user installed kdelibs into, one where the
application has been installed to and one is $HOME/.kde, but there
may be even more. Under these prefixes there are several well
defined suffixes where specific resource types are to be found.
For example for toolbar icons that is share/toolbar and
share/apps/<appname>/pics.


So the search algorithm basicly appends to each prefix each registered
suffix and tries to locate the file there.
To make the thing even more complex, it's also possible to register
absolute paths that KStandardDirs looks up after not finding anything
in the former steps. They can be useful if the user wants to provide
specific directories that aren't in his $HOME/.kde directory as
example for icons.

=== On the usage of <tt>locate</tt> and <tt>locateLocal</tt> === 


locate and locateLocal are both convenient functions that make the use of
KStandardDirs as simple as possible. You have however the possibility to
use the full power of KStandardDirs without them.


Typical KDE applications use resource files in one out of three ways:


* A resource file is read but is never written. A system default is supplied but the user can override this default in his local .kde directory:


<syntaxhighlight lang="cpp-qt">
// Code example
myFile = locate("appdata", "groups.lst")
myData = myReadGroups(myFile);
</syntaxhighlight>


* A resource file is read and written. If the user has no local version of the file the system default is used. The resource file is always written to the users local .kde directory.


<syntaxhighlight lang="cpp-qt">
// Code example
myFile = locate("appdata", "groups.lst")
myData = myReadGroups(myFile);
...
doSomething(myData);
...
myFile = locateLocal("appdata", "groups.lst");
myWriteGroups(myFile, myData);
</syntaxhighlight>


* A resource file is read and written. No system default is used if the user has no local version of the file. The resource file is always written to the users local .kde directory.


<syntaxhighlight lang="cpp-qt">
// Code example
myFile = locateLocal("appdata", "groups.lst");
myData = myReadGroups(myFile);
...
doSomething(myData);
...
myFile = locateLocal("appdata", "groups.lst");
myWriteGroups(myFile, myData);
</syntaxhighlight>


''Initial Author:'' Stephan Kulow [mailto:coolo@kde.org (coolo@kde.org)]


[[Category:KDE3]]
[[Category:Architecture]]
[[Category:Developers]]

@@ Line 9: / Line 9: @@
 <!--T:4-->
-Similiar to that concept TDE separates search paths for different
+Similiar to that concept, TDE separates search paths for different
 things to make it simpler to add paths for a specific resource without
 making a lookup for another resource unnecessary slower and without
 requiring you to put everything into one directory.
+= Resource types =
 <!--T:5-->
 {{Outdated|2022|04|21|reason=Might need to be updated according to docs.}}
@@ Line 42: / Line 43: @@
 tools provided for TDE (e.g. tdevelop) will know about. -->
-== TDEStandardDirs == <!--T:13-->
+= TDEStandardDirs = <!--T:13-->
 <!--T:14-->
@@ Line 78: / Line 79: @@
 example for icons.
-=== On the usage of <code>locate</code> and <code>locateLocal</code> === <!--T:18-->
+== On the usage of <code>locate</code> and <code>locateLocal</code> == <!--T:18-->
 <!--T:19-->

@@ Line 1: / Line 1: @@
+Trinity offers several ways to access the files that your application
-== Overview == <!--T:2-->
-<!--T:3-->
-KDE offers several ways to access the files that your application
 installed on your user's hard disc while making it transparent
 to you where the data really are. To allow the user (or adminstrator
-in most cases) to move files where he sees them fit best, KDE offers
+in most cases) to move files where they see them fit best, TDE offers
 a list of different resource types for which a different search path
 is assigned to. You may have heard of the environment variable <tt>PATH</tt>
@@ Line 12: / Line 9: @@
 <!--T:4-->
-Similiar to that concept KDE seperates search paths for different
+Similiar to that concept TDE separates search paths for different
 things to make it simpler to add paths for a specific resource without
 making a lookup for another resource unnecessary slower and without
@@ Line 18: / Line 15: @@
 <!--T:5-->
+{{Outdated|2022|04|21|reason=Might need to be updated according to docs.}}
-The types of resources KDE offers are
+The types of resources TDE offers are
 <!--T:6-->
@@ Line 27: / Line 25: @@
 * data - where applications store data
 <!--T:8-->
-* exe - executables installed privatly for KDE's use
+* exe - executables installed privatly for use by the desktop environment
 * html - HTML documentation
 <!--T:9-->
 * icon - application icons to appear in the window manager or the panel
-* lib - libraries and to be dlopened modules
+* lib - libraries and to be <code>dlopen</code>ed modules
 <!--T:10-->
-* locale - translation files for KLocale
+* locale - translation files for TDELocale
 * mime - mime types
 <!--T:11-->
@@ Line 41: / Line 39: @@
 <!--T:12-->
-For all of them exist also Makefile aliases that configures created by the development
+<!-- For all of them exist also Makefile aliases that configures created by the development
-tools provided for KDE (e.g. kdevelop) will know about.
+tools provided for TDE (e.g. tdevelop) will know about. -->
-== KStandardDirs == <!--T:13-->
+== TDEStandardDirs == <!--T:13-->
 <!--T:14-->
-This is one of the most central classes in kdelibs as
+This is one of the most central classes in tdelibs as
 it provides a basic service: it knows where the files
-reside on the user's harddisk. And it's meant to be the
+reside on the user's hard disk. And it's meant to be the
 only one that knows - to make the real location as
 transparent as possible to both the user and the applications.
@@ Line 58: / Line 56: @@
 (e.g. apps) and a filename (e.g. Home.desktop). In an ideal world
 the application would make no assumption where this file is and
-leaves it up to <tt>KStandardDirs::findResource("apps", "Home.desktop")</tt>
+leaves it up to <code>TDEStandardDirs::findResource("apps", "Home.desktop")</code>
 to apply this knowledge.
 <!--T:16-->
-The main idea behind KStandardDirs is that there are several
+The main idea behind TDEStandardDirs is that there are several
 toplevel prefixes where files are below. One of this prefixes is
-the one where the user installed kdelibs into, one where the
+the one where the user installed tdelibs into, one where the
-application has been installed to and one is $HOME/.kde, but there
+application has been installed to and one is <tt>$HOME/.trinity</tt>, but there
 may be even more. Under these prefixes there are several well
 defined suffixes where specific resource types are to be found.
-For example for toolbar icons that is share/toolbar and
+For example for toolbar icons that is <tt>share/toolbar</tt> and
-share/apps/&lt;appname&gt;/pics.
+<tt>share/apps/&lt;appname&gt;/pics</tt>.
 <!--T:17-->
-So the search algorithm basicly appends to each prefix each registered
+So the search algorithm basically appends to each prefix each registered
 suffix and tries to locate the file there.
 To make the thing even more complex, it's also possible to register
-absolute paths that KStandardDirs looks up after not finding anything
+absolute paths that TDEStandardDirs looks up after not finding anything
 in the former steps. They can be useful if the user wants to provide
-specific directories that aren't in his $HOME/.kde directory as
+specific directories that aren't in their $HOME/.kde directory as
 example for icons.
-=== On the usage of <tt>locate</tt> and <tt>locateLocal</tt> === <!--T:18-->
+=== On the usage of <code>locate</code> and <code>locateLocal</code> === <!--T:18-->
 <!--T:19-->
-locate and locateLocal are both convenient functions that make the use of
+<code>locate</code> and <code>locateLocal</code> are both convenient functions that make the use of
-KStandardDirs as simple as possible. You have however the possibility to
+TDEStandardDirs as simple as possible. You have however the possibility to
-use the full power of KStandardDirs without them.
+use the full power of TDEStandardDirs without them.
 <!--T:20-->
-Typical KDE applications use resource files in one out of three ways:
+Typical TDE applications use resource files in one out of three ways:
 <!--T:21-->
-* A resource file is read but is never written. A system default is supplied but the user can override this default in his local .kde directory:
+* A resource file is read but is never written. A system default is supplied but the user can override this default in their local .trinity directory:
 <!--T:22-->
@@ Line 101: / Line 99: @@
 <!--T:23-->
-* A resource file is read and written. If the user has no local version of the file the system default is used. The resource file is always written to the users local .kde directory.
+* A resource file is read and written. If the user has no local version of the file the system default is used. The resource file is always written to the users local <tt>.trinity</tt> directory.
 <!--T:24-->
@@ Line 116: / Line 114: @@
 <!--T:25-->
-* A resource file is read and written. No system default is used if the user has no local version of the file. The resource file is always written to the users local .kde directory.
+* A resource file is read and written. No system default is used if the user has no local version of the file. The resource file is always written to the users local <tt>.trinity</tt> directory.
 <!--T:26-->