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

List:       kfm-devel
Subject:    Re: corbifying kget
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-03-22 15:30:48
[Download RAW message or body]


On Sun, 21 Mar 1999, Matt Koss wrote:

> On Ne, 21 mar 1999, Simon Hausmann wrote:
> >On Sun, 21 Mar 1999, Matt Koss wrote:
> >
> >1) I think we should let the views implement yet another signal, just
> >like:
> >signal void newTransfer( in string source, in string destination );
> >
> >The MainView then can connect to this signal and emit an event to itself.
> >If KGet is installed as plugin this event gets filtered and KGet can
> >process the download.
> >If the event is not filtered the MainView will handle the download itself
> >by starting an KIOJob and displaying the download progress in a section in
> >the statusbar.
> 
> Ok, will you implement these signals ?
> 
> As for the events, will the following  be OK ?  :
> 
> konqueror.idl :
> ----------
>    struct Transfer  {
>         string source;
>         string destination;
>     };
>    typedef Transfer EventNewTransfer;
>    const string eventNewTransfer = "Konqueror/NewTransfer";
> 
> kget.h :
> -----
> a.)  class KMainWidget : public KTopLevelWidget, virtual public KOMBase
> 
> b.)  virtual bool addTransfer( QString src, QString dest );
>     virtual CORBA::Boolean eventFilter( KOM::Base_ptr obj, const char* type..)
> 
> kget.cpp :
> -------
> CORBA::Boolean KMainWidget::eventFilter( KOM::Base_ptr obj, const char* type,
> 					 const CORBA::Any& value )
> {
>   EVENT_MAPPER( type, value );
>   MAPPING( Konqueror::eventNewTransfer, Konqueror::Transfer, addTransfer );
>   END_EVENT_MAPPER;
>   return false;
> }

Unfortunately it isn't that easy :(

First of all I suggest a proper IDL description of KGet's interface:

#include <kom.idl>

module KGet
{
  interface TransferPlugin : KOM::Plugin
  {
    //some nice stuff here perhaps
  }

}

And then in KGet:

class TransferPluginFactory : virtual public KOM::PluginFactory_skel
{
public:
  TransferPluginFactory( const CORBA::ORB::ObjectTag &tag );
  TransferPluginFactory( CORBA::Object_ptr obj );

  KOM::Plugin_ptr create( const KOM::Component_ptr comp );
};

TransferPluginFactory::TransferPluginFactory( const CORBA::ORB::ObjectTag
&tag ) : KOM::PluginFactory_skel( tag )
{
}

TransferPluginFactory::TransferPluginFactory( CORBA::Object_ptr obj )
: KOM::PluginFactory_skel( obj )
{
}

KOM::Plugin_ptr TransferPluginFactory::create( const KOM::Component comp )
{
  return KOM::Plugin::_duplicate( new KGetTransferPlugin( comp ) );
}

class KGetTransferPlugin: virtual public KOMComponent,
                          virtual public KGet::TransferPlugin_skel
{
public:
  KGetTransferPlugin( KOM::Component_ptr );

  /*
   ...
   */

  virtual CORBA::Boolean eventFilter( KOM::Base_ptr obj, const char *type,
const CORBA::Any &value );

  // more stuff here if wanted
} 

KGetTransferPlugin::KGetTransferPlugin( KOM::Component_ptr comp )
{
  KOM::EventTypeSeq seq;
  seq.length( 1 );
  seq[0] = CORBA::string_dup( Konqueror::eventNewTransfer );

  comp->installFilter( this, "eventFilter", seq, KOM::Base::FM_IMPLEMENT
); // ...or whatever you like as FilterMode ;)
}

KGetTransferPlugin::eventFilter( KOM::Base_ptr obj, const char *type,
const CORBA::Any &value );
{
  //get the event structure out of "value" and start a new transfer here
}

...

main()
{
  KOMApplication app( argc, argv );

  KOMAutoLoader<TransferPluginFactory> factoryAutoLoader;

  more kget specific stuff here

  app.exec();
}

In addition you need some entries in KGet's .kdelnk, but I did not have
the time, yet, to write the relevant code in Konqueror, so I can't tell
you now what it should look like.
And: All the stuff above is just an proposal/idea, I didn't test the above
code or so -> There might be thousands of bugs... :)

> >2) There's no need for writing a script to install KGet as plugin in
> >Konqy: Konqueror will handle all this for you, KGet will just need some
> >special entries in it's .kdelnk file plus a proper autoloader for a
> >PluginFactory, creating KGet KOM plugin components.
> >(ah, ...and KGet will have to link against the IDL generated code from
> >konqueror.idl)
> 
> Does it mean, that I don't need to add any calls to installFilter()
> in order to install KGet as a filter for EventNewTransfer ?

You need, but Konqueror will do the server startup for you and
call your plugin factory.
 
> And what's that autoloader for PluginFactory ?

The plugin factory is meant to create new plugin object upon request via
create() .

> Another thing is, what if other applications want to utilize kget for doing
> the transfer.
> A guess that they would have to emit EventNewTransfer and this will end in kget
> somehow ?

Other apps might perhaps want to use an additional KGet interface directly
or use the factory to create a plugin. Then the app would need to emit the
specific transfer event to itself (or wherever the KGet event filter
listens)

In addition we need some extensions to the current (on my harddisk
sitting) plugin system for Konqy.
But unfortunately I have some veryveryvery important exams in a few weeks
and I have to prepare for them ==> I have currently quite no time for
KDE/Konqueror, but I will commit my already written plugin code ASAP
(...if kimgioRegister() wouldn't be broken anymore I could do more testing
and commit everything tonight :-/

But as soon as I have finished my exams I will have hopefully enough time
to help integrating KGet into Konqy :)


Greetings,
 Simon

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