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

List:       kfm-devel
Subject:    Re: caitoo - konqy
From:       weis () stud ! uni-frankfurt ! de
Date:       1999-04-15 10:02:33
[Download RAW message or body]

Hi,

On Fri, 9 Apr 1999, Simon Hausmann wrote:

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

Doing it at runtime is the best in theory, but I realized
that starting plugins takes some time. Look at photoshop starting
with many plugins. Whatever they do, I dont know, but it takes too
long.

That is the reason why I do it different in KOffice.

However, I realized in the meantime, that some plugins want
to change ( enable/disable ) their buttons as events come in.
So they need to be running from the very beginning.

I think there i no way around making both work.

Bye
Torben

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