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

List:       kfm-devel
Subject:    Re: krun <-> ktrader
From:       David Faure <david.faure () insa-lyon ! fr>
Date:       1999-06-07 15:00:39
[Download RAW message or body]

Very nice solution !

I guess kded would provide the implementation of a derived
KServiceProvider, right? But where would it be built ?
It would be nice if the app didn't have to care about that...

Perhaps in the KRemoteTrader instance ?
mmmh.. doesn't let the choice to the app... needs more thinking.

On Mon, Jun 07, 1999 at 01:24:09PM +0200, Simon Hausmann wrote:
> Hi,
> 
> Problem: KRun requires the registry to be loaded
> 
> More specific: KServiceTypes aren't a big problem, they don't eat much
>                memory, but KService eats memory. The only calls to
>                KServiceTypeProfile are in KRun::runURL, so this would be
>                the only function we'd need to modify, in order to get a
>                more flexible KRun, so that we could use KTrader in Konqy,
>                KDesktop (oops, renamed to KDesky, according to how David
>                named that one function in kfmclient ;) ) and KPanel.
> 
> Solution IMHO: Make KRun configurable in such a way that it can use
>                KServiceTypeProfile directly, like it is currently done
>                everywhere, or an additional KService "provider", like
>                KTrader.
> 
> Possible approach: I like the way David solved the openFileManagerWindow
>                    problem in libkio. I thought of a similar way, with
>                    something like KServiceProvider, using
>                    KServiceTypeProfile as default.
> 
> Proposal:
> 
> class KServiceProvider
> {
> public:
>   KServiceProvider() { s_pServiceProvider = this; }
>   virtual ~KServiceProvider() {};
> 
>   virtual const KService *service( const char *mime_type );
> 
>   ...similar to KFileManager
> };
> 
> I think returning one single KService pointer should be sufficient, since
> KRun uses only one anyway.
> 
> 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]