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

List:       kfm-devel
Subject:    Remove
From:       mike wong <xcyberghost () yahoo ! com>
Date:       1999-06-05 15:01:11
[Download RAW message or body]

remove me from this list

--- David Faure <david.faure@insa-lyon.fr> wrote:
> On Fri, Jun 04, 1999 at 01:03:38AM +0200, Simon
> Hausmann wrote:
> > But perhaps I'm missing another possibility.
> > Does anyone have an idea?
> Yes, you :)  Below.
> 
> I think your idea is 100% right.
> You have my vote :)
> 
> However, does it solve the
> "konqueror-should-IMHO-register-to-kded-on-startup"
> problem ?
> It doesn't seem so....
> 
> > > > As a workaround to this we could make
> konqueror bind its application
> > > > object (which is usually loaded by the
> autoloader otherwise) to a fixed
> > > > name in the naming service. But of course only
> if this hasn't been done by
> > > > another instance already.
> > > Yup.
> > > 
> > > > Now we could make kfmclient look up in the
> naming service for konqy and
> > > > use it instead of asking kactivator to
> possibly start a new service.
> > > Why "instead of" ? Can't we simply make the
> activator use konqueror's registration ?
> > 
> > Which registration? ;-)
> > The problem is that only a konqueror process which
> got started from the
> > mediators is able to register itself as running
> server. At least I see no
> > other way.
> I don't see why.
> The kded IOR is on the root properties, so konqueror
> can connect to it
> some way, right ? (I mean konqueror can ask libkded
> to connect to it)
> 
> > (and the registration from the .desktop file
> doesn't tell anything about a
> > running instance)
> Sure :)
> 
> > Hm, wait, I have another idea how we could make
> things prettier and
> > smaller. We could avoid running another memory
> eating daemon process (nsd)
> > by implementing our own little naming service in
> kded. 
> > 
> > We don't need a complex beast with multiple naming
> contexts and stuff, so
> > a simple QMap<QString,CORBA::Object_var> could do
> it :-))
> > 
> > *going wild now*
> > And we could perhaps make KActivator look for a
> running server at this
> > pseudo-mini-naming service before asking the
> mediators.
> > 
> > To make things configurable this behaviour could
> be specified in each
> > service's .desktop file.
> > 
> > (this way we wouldn't even need to modify
> kfmclient or any other client
> > app using kactivator :) , just the servers)
> > 
> > Nevertheless we have to be careful with apps like
> Konqueror, because we
> > can't allow the user to really shutdown konqueror
> when he closed all
> > windows but there's still another app "using" it.
> Well, we have to catch exceptions and restart a
> server if it doesn't
> answer the calls...
> 
> > P.S.: Another ugly thing with kded is that it
> currently doesn't shutdown
> >       servers when they aren't needed anymore.
> >       But I'm currently trying to implement the
> needed functionality into
> >       KOM, so that the server shuts itself down :)
> Great!
> 
> -- 
> 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
> 
> 

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

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