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

List:       kfm-devel
Subject:    krun <-> ktrader
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-06-07 11:24:09
[Download RAW message or body]

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>

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