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

List:       kfm-devel
Subject:    (kded/registries/konqy) Re: kdelibs/corba/kded
From:       David Faure <david.faure () insa-lyon ! fr>
Date:       1999-05-30 20:35:00
[Download RAW message or body]

[making public a discussion started privately for no particular reason]

> Torben wrote :
> > David wrote :
> > There is the problem of using KSharedPtr for services in kded - see kde-cvs
> > and also :
> 
> KSharedPtr is buggy. I changed the semantics a bit. But have to fix
> the code that uses it first. So where is your problem ?
It has been fixed by using KSharedPtr in KServiceEntry.

> > In order to use kded in konqueror, query() is not enough.                      
> > konqueror (in fact libkonq/kpopupmenu.cc) needs first to get                   
> > the mimetype for a given URL. What are the plans about it ?                    
> > We don't want to create the registry in konqueror, right ?                     
> 
> Would be waste of time and resources.
> 
> > Implement it in the kded idl ?                                                 
> 
> Seems like the right way, but: No.
> I had problems with good old KFM to get mime type detection up to speed.
> If Konqueror shows a dir with 500 files and makes 500 CORBA calls for
> the mimetype stuff alone then our user might be pissed of because that
> is slow. Kregistry can write a nice binary format of itself anyway. So
> perhaps it would be better to load the in konqueror. Will cost memory
> but will make things fast.

Well, what about splitting ?
The _mimetype_ registry has to be loaded in konqueror, for fast browsing, sure.
But the _applications_ (=services) registry is only needed when some
application is started (popupmenu for instance), so konqy could ask kded
for that matter.

> All other apps should indeed ask kded.
At least CORBA-based apps. Linking to kded+corba just to have some
mimetype info is too much IMHO (e.g. krn uses some mime-type stuff like
kmimemagic, which is in kio, no need for kded)

> > (In this case, it looks like all other static methods of KServiceType/KMimeType
> >  and KService should be implemented. Only static ones, since when we have a    
> >  real object we can use it directly.)                                          
> >                                                                                
> > or ?                                                                           
> 
> May be. Since every function end every struct in IDL makes unbelievable
> bloat I would suggest to implement as few stuff via IDL as only possible.
> Most important of all: No convenience functions in IDL. We can still make
> a wrapper around to make it easier to use. But the output of the IDL
> compiler is reallllyyy big!
Very good point. We'll remember it when designing IDL files.

> PS: I get the fealing that discussing kded design via mail is really a 
> pain. What a pitty that KDE II is not in direct reach. Does anybody
> of you come to LinuxTag in Kaiserslautern ? I assume not, or ?
Alas not.

Using shared mem is also being suggested.
I know nothing about it - seems powerful and rather complex, but
is it available everywhere ?

My point is : if we keep the current design / way of doing things /
then the solution is to load only the mimetype registry in konqy and
use kded for services. If not I don't know.

-- 
David FAURE
david.faure@insa-lyon.fr, faure@kde.org
http://www.insa-lyon.fr/People/AEDI/dfaure/index.html 
KDE, Making The Future of Computing Available Today

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