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

List:       kde-devel
Subject:    Re: KPanel - KTrader(kded)
From:       David Faure <david.faure () insa-lyon ! fr>
Date:       1999-06-08 22:14:07
[Download RAW message or body]

Great idea, Torben !

Torben-The-God-of-KDE's brain still works very well !

Yes, this is a very nice compromise.

Well, I see nothing else to comment :)

On Wed, Jun 09, 1999 at 12:03:34AM +0200, weis@stud.uni-frankfurt.de wrote:
> Hi,
> 
> here are some thoughts about reading mimetype infos fast.
> I realized that I have MANY mimetypes on my harddisk as
> mimetype.kdelnk files, but most of my files are of few
> mimetypes like text/* or some few image/*.
> 
> I dont have the files with mimetype video/* etc. on my disk,
> so why loading them in memory.
> 
> The idea that comes from that is easy. We will only load initially
> the information: We know a mimetype like that and this is the
> filename pattern. In addition we have the mimemagic stuff.
> 
> Currently we have in addition in memory: infos about icon,
> comment, preferred apps. Since mimetypes are just some sort
> of servicetype, the information about some servicetype may
> even increase in the future.
> 
> So lets load only the filename pattern "*.cpp;*.cc" and that like
> and save where further information can be retrieved. For example
> kded could watch changes in the mimetypes directory and send
> update informations. In addition kded could create a list which
> holds only this minimum information: The filename pattern.
> 
> Once a power app like konqueror detects that it needs more information
> about a servicetype we can still load all the infos.
> 
> Advantages:
> 
> - Fast startup. Instead of opening hundreds of files, we open
>   the summary file written by kded.
> - Few memory since we only load infos about mimetypes that
>   we really need.
> 
> Implementation:
> 
> Just do it in KServiceType. It needs a flag telling that
> most of the information is absent. Once such infos
> are requested, KServiceType could load the rest.
> 
> What do you think ?
> 
> Bye
> Torben
> 
> 
> On Tue, 8 Jun 1999, Simon Hausmann wrote:
> 
> > On Tue, 8 Jun 1999, Harri Porten wrote:
> > 
> > > Martin Konold wrote:
> > > > 
> > > > On Tue, 8 Jun 1999, Simon Hausmann wrote:
> > > > 
> > > > > Advantage:
> > > > > - no more need to load the .desktop files in applnk for KRun
> > > > >   (-> KPanel eats less memory)
> > > > >
> > > > > Disadvantage:
> > > > > - KPanel requires and depends on kded
> > > > > (although I'm not sure whether this is a disadvantage ;-)
> > > > 
> > > > kpanel is maintained by Matthias E. you can of course apply the patch but
> > > > it is easily possible that Matthias will revert it if he doesnt like it
> > > > ;-)
> > > > 
> > > > IMHO a dependency on kded is no big disadvantage. I expect kded to run all
> > > > the time anyways ;-)
> > > 
> > > That's quite an important issue: how far will the corba'fication go ? We
> > > have to decide this now. Personally I'm pro going this way (cause it's
> > > challenging and interesting;) but people who don't have too much memory
> > > in their machine will disagree. They might not understand why they need
> > > a daemon (final size unknown yet) for an application launcher.
> > 
> > People with not enough memory running kded will be lost with KDE 2.0
> > anyway I fear. Both, KDesktop and Konqueror require (and use) it, and I
> > consider both apps be to meant for "daily" usage for the average user.
> > I mean: Who wants to run KDE without a desktop for example? ;-)
> > 
> > And in fact kded is a helping hand when it comes to saving memory,
> > although I admit that libmico&friends are indeed "huge" .
> > The helping hand you might ask?
> > Well, many apps need "access" (in different ways) to the registry.
> > And providing a single instance in the whole desktop environment which
> > takes care about managing/loading the registry and which shares this data
> > looks ok to me, or?. At least IMHO this is better than requiring every
> > client application to load everything (unshared stuff) .
> > 
> > I agree that kded is currently really a big beast in memory (on my system
> > I have somewhat around 15mb or so, which is far to much IMHO) , but it
> > isn't the code/executable/library which makes it big I think, it's the
> > KService/KServiceType data (at least this is the only thing I could think
> > of) . If I'm not wrong and it's really KService&friends which eat all the
> > memory, then we should really find a way to "slim" the beast :-) .
> > 
> > Indeed kded is far from being finished IMHO, but it reached a usable state
> > I believe. And IMHO it's better to use a still bloaty daemon rather than
> > requiring every client app to bloat itself up with unshared data. And
> > since I believe that the general API is somewhat "stable" IMHO it makes
> > sense to make possible client apps use it now. If we find better and more
> > efficient ways to share data between client apps and kded, then all the
> > interfaces are really flexible enough IMHO to change the background
> > mechanism of transferring the data for example, but still keeping source
> > compatibility.
> > 
> > But, taking an idea of Torben, we have to distinguish between the clients
> > and what kind of information they want to have. Let me quote a mail from
> > him, from kfm-devel:
> > >[...]
> > >IMHO we have to distinguish between apps which need ALL informations
> > >about something and apps which need SOME/ONE informations about some
> > >Topic.
> > >
> > >Konqueror: ALL mimetypes, ONE/FEW infos about services at a time
> > >KMail: The same
> > >Kded: ALL services
> > >kpanel: Like konqueror.
> > >
> > >So what do we learn ?
> > >
> > >IMHO: Services can be accessed via CORBA or kfmclient like stuff since
> > >I dont know a app which needs ALL infos about ALL services very fast.
> > >Only Kded needs that.
> > >
> > >The stuff that many apps need ALL infos about os the mimetypes
> > >and corresponding icons stuff. So we should try to optimize that.
> > >
> > >Simple way: CORBA. To slow to get ALL informations.
> > >
> > >IMHO we can focus on the discussion how to get infos about ALL
> > >mimetypes/icons and how to do fast kmimemagic stuff.
> > >
> > >Since mime types may change, we need a central app which looks
> > >at the changes -> kded ?
> > 
> > I can only agree with this. 
> > But I'm clueless about how we can do fast mimetype detecting without
> > requiring every app to load the necessary stuff.
> > 
> > As already often discussion shared memory might be a solution. Perhaps
> > someone has a practical idea/proposal how to implement this, using mm lib
> > (this Engelschall thing) ??
> > 
> > But beside the mimetypes problem, the current way of getting KService data
> > is fine IMHO, and that's why I think making KPanel ask kded for such data
> > instead of loading it itself is a nice thing, or?
> > 
> > 
> > > Matthias' latest words on kpanel indicated that he planned to develop
> > > applets without the help of CORBA btw.
> > 
> > I had a discussion about that with Mosfet on irc, too, and we both
> > share(d) the opinion that using CORBA stuff (for example OpenParts) is not
> > really necessary for applets. But that are just two (one) opinions :-)
> > 
> > 
> > Ciao,
> >   Simon
> > 
> > --
> > Simon Hausmann       <hausmann@kde.org>
> > http://www.kde.org/  <tronical@gmx.net>
> > 
> > 
> > 
> > 
> > 

-- 
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]