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

List:       kfm-devel
Subject:    Re: caitoo - konqy
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-04-08 12:59:05
[Download RAW message or body]


CC'ing this to kfm-devel: It might be a good idea to discuss this first
rather than implementing first and then see disadvantages...

On Thu, 8 Apr 1999, Matt Koss wrote:

> 
> Hi Simon,
> 
> I was looking at your changes in caitoo and I want to thank you for your help
> with CORBA stuff. I guess I am still kind of confused from all these plugins etc.

First of all: I'm sorry, I should have informed you sooner about my
ideas/plans/changes. Well, time to do it now :-)

First my ideas about component integration in konqueror in general:
(warning: I'm not talking about VIEW plugins)

1) the goal - components inside konqueror
I think it's the best to provide a very standard and general way of
integrating possible plugin components. This means Konqueror itself
doesn't know _what_ a plugin actually _does_ , it just knows: "Ah, this
thing wants to do something with me. Ok, I'll let it in ". In regard to
the actual implementation I think it's the best to use KOM's plugin
mechanism. 

2) an idea - how the actual implementation _could_ look like
I now assume that we already have Torben's nice trader and I also assume
the existance of the following servicetype (hint: see
$CVSROOT/koffice/trader/data/servicetypes :-P )

'serviceType' 'KOMPlugin'
{
  'SuperTypes'<@string> = { 'KOMComponent' };
  'Interface'<string> = 'IDL:KOM/PluginFactory:1.0";
  'properties' 'properties'
  {
    'property' 'RequiredInterfaces'
    {
      'Type'<string> = '@string' ;
    };

    ...

  };
};

Now we ask the trader for objects supporting this service type and
requiring "IDL:Konqueror/MainView:1.0" as interface (see
RequiredInterfaces property) .

Bingo, the rest should be quite easy:
Since the provided object references support the PluginFactory interface
we can now easily call MainView->addPlugin(...) with the corresponding
arguments :-)

What now happens is: When the actual plugin is created (and we might force
this by default) the create() method of the plugin factory gets called,
having the mainview component as argument.
This way the factory gets a reference to the mainview, can create a
new plugin object and give this object "access" to the mainview object
(and return a reference of this plugin component to the mainview itself).
The plugin object can now for example install an event filter for
"newTransfer" (greetings to Matt :-) ) or do whatever it wants to do ;-) .


3) the other way around...
But of course with the trader there's also another possible way:
Let's say application xyz gets started and wants (beside it's core
functionality) install a plugin component into a running mainview object
(or whatever it else could want to do) . Now it asks the trader for
running objects supporting the "IDL:Konqueror/MainView:1.0" interface and
this way has access to the mainview.


Now my questions: 
 1) Torben - Will your trader be able to do this?
 2) Did I miss anything?
 3) Please show me missing points...

:-)

This means for Caitoo:
I'd rather way with the further implementation a few days and see what the
future brings :] .
I hope we then know how Caitoo
 a) gets started up (executed)
 b) registers its service at the kded 

> Some questions :
> 
> 1. I am still not sure about how everything should be started.
>     I saw that kview uses --server option. I guess that this is needed, because
>     kview can be started also separately. Do you think that this should be done
>     also in caitoo ?
>
> 2.  My first IDL code contained also declaration of method
>        void addTransfer( const Konqueror::Transfer& transfer ) ;
>     As I understood, for filtering out the Konqueror event "newTransfer" this is
>    not needed. But what about if other apps want to add transfer to caitoo ?
> 
>     I mean, do we need to add this to caitoo.idl, or these other apps would ask
>     Konqueror to do transfer and Konqueror would consequently ask caitoo ?

Ooops, my fault, I think addTransfer should be added again to caitoo.idl
... :-)
 
> 3. caitoo.kdelnk - what's the difference between service types
>      KonquerorMainViewKOMPlugin and KonquerorEventFilter ?

Kind of obsolete/depreceated names ;-)
Let's see how we can do it with kded
 
> 4. I saw your comment about caitoo crashes in KMainWidget constructor.
>     For me it works, so I am not sure what could be the problem.

I have the impression that it might be the current Qt. At least gdb's
backtrace points somehwere into Qt, and a few days before everything
worked fine (at least Konqy) .
But I'm not sure about this since other apps seem to work fine...

Greetings,
 Simon 

> 
> Kind regards
> 
> 		Matt
> 
> --
> Matej Koss	e-mail: koss@napri.sk
> Kosice		ICQ#  : 19344305
> Slovakia
> 

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