[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kded excluding dirs?
From:       Stephan Kulow <coolo () kde ! org>
Date:       1999-12-02 12:23:34
[Download RAW message or body]

weis wrote:
> 
> Hi,
> 
> On Thu, 2 Dec 1999, David Faure wrote:
> 
> > > On Sun, Nov 28, 1999 at 01:57:04PM +0000, David Faure wrote:
> > >
> > > Hi,
> > >
> > > > > is it possible to configure kded which directories to watch for new
> > > > > mimetypes, .desktop-files, et al?
> > > > > I imagine our university network, where the KDE-installation is quite
> > > > > static (you wouldn't need to run kded at all), but with KDEDIRS, a
> > user
> > > > > could install his own additions, where kded would make sense.
> > > > > So could I tell kded to watch e.g. ~/kde, but not /usr/KDE?
> > > > If you do that you need a full copy of the
> > mimetype+apps+services+servicetypes
> > > stuff in ~/.kde, otherwise it won't work...
> > >
> > > ideally, kded shouldn't need to recreate the entire ksyscoca-file, but
> > > instead only update/remove/add changed items.
> > > But I guess you would have implemented that already, if it
> > > would be easily possible. Otherwise, one could tell kded to not use
> > KDirWatch on the
> > > global stuff, but to restrict it to local files. If something changes,
> > > well, recreate the entire ksycoca, but at least don't monitor
> > > it all the time.
> >
> > No, that's not how kded/ksycoca has been designed.
> > (If you want to do add/update/... you either need to keep things in kded's
> > memory,
> > which we don't want, and you can't just append something to the file since
> > all indexes
> > have to be updated).
> >
> > I think the best solution is to have an option "only scan user's dirs"
> > that does what it says : only adds user's dirs to KDirWatch, not global
> > dirs,
> > but when the ksycoca file is recreated, it will recreate the whole file,
> > reading the files on the global dir as well.
> >
> > The only case where this breaks is if admins decide to change a global file,
> > but that's where the compromise is.
> >
> > OTOH since kded runs on startup, every one will get the new settings
> > on the next logon.
> 
> IMHO that is a cool optimization. It will work quite well in large
> environments with sysadmins (like university) while the current
> method is better for peoples home workstation where they install
> new software every second day in the global environment.
> 
> There comes a question to my mind: Did anybody test or at least
> think about installing new apps (including binary and libs)
> in a users home directory?

Well, I never tested it, but a export KDEDIRS=$KDEDIRS:$HOME/myapp
should do the trick. kded needs to know that of course, but I don't
know a way around that. BTW: You can also get around expanding KDEDIRS
in adding 
[Directories]
prefixes=$HOME/myapp
to /etc/kderc. I kind of doubt that kded triggers that file, but
kwmcom reconfigure should rescan that :)

Greetings, Stephan

-- 
When your memory goes, forget it!

[prev in list] [next in list] [prev in thread] [next in thread]