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

List:       kde-multimedia
Subject:    quick mcopclass search (Re: kaiman !?)
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-11-13 19:12:43
[Download RAW message or body]

   Hi!

On Sat, Nov 11, 2000 at 11:18:55AM +0100, Martin Vogt wrote:
> > > If we define a common directory where the .mcopfiles go,
> > > we need to fix arts and artspluggy maybe artsbuilder
> > > and that should be all.
> > > (simple change in Makefile.am.)
> > > 
> > > Maybe I forgot something?
> > 
> > The problem are applications which come with their own .mcopclass files. You
> > are encouraged to do this, for instance, if you write a drum machine for KDE2,
> > add your own sample playing modules, or even just a new file format.
> > 
> > These apps will expect the .mcopclass files to go in the same directory where
> > the KDE libraries are. If such an application installs/works fine with KDE2.0,
> > it will not install/work fine with KDE2.0.1, and the other way round. Their
> > Makefiles will contain lines like
> > 
> > mcoptypedir = $(libdir)
> No it should contain this:
> 
> mcoptypedir = $(mcopdir)
> 
> and in configure.in mcopdir=$KDEDIR/lib/mcop or anything else.

Maybe, but we can't really change what apps should do when KDE2.0 is the
reference version. Apps will do what works with KDE2.0, and what is
documented for instance in the docs that come with 2.0, or the KDE2.0
Development book. And they will be right doing so, so I think trying to
be backward compatible is really a good idea.

Besides, if the application did it like you describe, then under KDE2.0,
it would register "mcop::Foo::Bar" and under 2.0.1 "Foo::Bar" by installing
/usr/lib/mcop/Foo/Bar.html. The path is relevant for which namespace the
interface gets registered in.

So what I did is writing a cache based version of the search for .mcopclass
files, and I think it should do the trick. Please, if you can, test it.
It's currently standalone. After building the cache file for the first time,
it should be pretty fast. It should be interesting to see how it performs

(1) if the filesystem cache is empty, i.e. directly after reboot
(2) if the filesystem cache is filled, i.e. after doing it once

To do the test, do

qsearchfinal <where kde libs are>   # <- example qsearchfinal /usr/lib

I have tested it myself, and hardly got anything which took more than half
a second for (1). For the other case, results were less than 0.1 seconds.
So please test, or be silent if it isn't fast for you when it goes into 2.0.1
;-)

The implementation is be link-safe, i.e. should be able to deal with
backlinks, and thus fix the Mandrake7.2 problem. You can get it at

   >>> http://space.twc.de/~stefan/kde/download/qsearchfinal.cc <<<

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

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