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

List:       kde-i18n
Subject:    Re: caitoo - konqy
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-04-09 11:22:27
[Download RAW message or body]


One thing I forgot to mention:
I could also think of an additional kind of plugin, similar to the KOffice
plugins. 

Perhaps with one difference: *Bar Entries are created/defined at
run-time, via the plugin's interface, in contrary to the koffice way,
where these entries are specified in the plugin's .kdelnk.

On the one hand the koffice way is nice because the plugin are only loaded
when necessary/used.

On the other hand specifing the *bar entries at run-time might be useful
as well.

Perhaps it makes sense to implement both?

Comments / Suggestions / Ideas ?

Bye,
 Simon

On Thu, 8 Apr 1999, Simon Hausmann wrote:

> 
> 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]