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

List:       kfm-devel
Subject:    Re: KPanel - KTrader(kded)
From:       weis () stud ! uni-frankfurt ! de
Date:       1999-06-08 22:03:34
[Download RAW message or body]

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

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