On Wednesday 08 February 2006 01:19, Waldo Bastian wrote:
> There are two different ways to address the problem associated with out of
> prefix installation: the first one is to tell out-of-prefix applications to
> install certain resources within a designated prefix. (e.g. under
> /usr/share or /usr/local/share),
>
> the second one is to provide applications with a way to register their
> location with the "system" (e.g. applications can edit /etc/man.config to
> add additional locations for manual pages and could edit /etc/kderc to add
> additional KDE resource directories), effectively extending the set of
> prefix'es. 

The second approach will kill the performance kbuildsycoca and other parts of 
KDE quickly due to the vast amount of extra folders that need scanning and 
thus the extra stat calls involved.

The first approach basically tells 3rd parties to still install files outside 
their own realm, which is exactly what we want to avoid.

What about the following third option? Currently all KDE resource handling 
(kbuildsycoca, KStandardDirs and all friends) look in several places that can 
be roughly described as $KDEHOME + $KDEDIRS for simplicity (and in this order 
as far as precedence goes).

Suppose we install a 3rd party app in $APPDIR, then for this application (and 
*ONLY* for this application) the resources should be looked for in $KDEHOME, 
$APPDIR, $KDEDIRS. If kbuildsycoca could create multiple sycocas (one for 
$KDEHOME, one for $APPDIR and one for all shared lower-level dirs combined)
and merge them then we can keep the performance level up and also keep apps in 
their own prefix. The existing full sycoca can (and probably should) be kept 
for performance reasons for the apps that reside in $KDEDIR.

App startup would then roughly be as follows:

1. App checks whether its binary is part of $KDEDIRS
2a. If yes, load the sycoca as we know it now and be done.
2b. If no, check if there is a partial sycoca for $APPDIR, and create it if
   it's missing. Next, load the partial sycocas for $KDEHOME and $KDEDIRS and
   merge the three.

This would work with all application-specific resources including (but not 
limited to) services and servicetypes, plugins, icons and xmlgui. The only 
case where it does not work is for stuff that needs to interact with other 
KDE apps (Konqueror service menus, mime type associations, K Menu 
entries, ...), but those are special anyway, and having 3rd parties take 
special measures for those is not a big deal. It can't be easily avoided, and 
all other major desktops, including Gnome and Windows, have a similar setup 
for making such resources show up properly.

-- 
Martijn