Plugins do work only with internalParser; proposal for DCOP interface (was: Re: [Kommander-devel] Plugins do not work with DCOP for me)

[Fabian Franz]

> > @HttpForm2.setURL runs localDCOPQuery("setUrl", "HttpForm2",
> > "www.google.de"), which runs DCOPQuery("kmdr-executor-678",
> "KommanderIf",
> > "setUrl", "HttpForm2", "www.google.de") [from kommanderfunctions.cpp]
> >
> > but KommanderIf does not know a function called setUrl as the list is
> > created by dcopidl2cpp and so static at runtime.
> >
> > The parser might have used f_internalDcop before and then it might have
> > worked or you are testing with the new parser?
> 
> Michal would have to answer this as I don't have time but now that you
> mention 
> it I know it was tested with the new parser.

I can now confirm:

It does only work with internalParser set to True, which is a huge problem for us, because we have ~1000 lines of code written in the old parser by several persons and such can't change.

> >
> > I don't know.
> >
> > All I know is that plugins with DCOP do not work for me and as Kommander
> > uses internally DCOP they do not work for me.
> >
> > And this sux ;-). Any help appreciated.

> What version of Kommander are you running? If you are developing you
> should 
> probably be running 1.3.0 although plugins should work with kdewebdev from
> any KDE after 3.3.0.

I have run kommander from kde 3.5.5 to kommander-1.3.0 compiled by myself.

Okay:

So here my next questions:

Would a patch that changes the execution of localDCOP to do something like f_internaldcop be accepted to have plugins run also via the old parser?

Next:

But in the long run, I would like to be able to access the new methods of my plugin also via DCOP.

What I do not understand is why all these DCOP calls are hardcoded?

I mean we get all the information about the widget from DCOP, can't you do this in a general way.

Two ideas here:

KommanderNewIf 
	-> WidgetName1 
		-> Functions of WidgetName1
	-> WidgetName2
		-> Functions of WidgetName2

And have a general functions Instance::interfacesDynamic, which is connected to the creation and deletion of Widgets.

And a Instance::functionsDynamic, which returns the registered functions of this Widget.

And a Instance::processDynamic, which translates the DCOP call via the known arguments of the function to:

WidgetName->processDCOP(<nr from specialfunction table>, list of arguments as strings).

However this is a still a crux, even if its quite backward compatible.

What I would really really like is to get rid of the <nr> alltogether as it can lead to conflicts with several plugins. 

Instead have the widgets directly handle the DCOP calls sent to them with a function type like DCOP::process.

The widget could also make use of the dcop idl interface to automatically create the DCOP::process function for the exported functions.

Because only a widget really knows what it exports and supports and I think it is ähm a bit strange to first get the DCOP information from the data stream, put it to a typed function. Only to then put it again in a untyped string list to convert it bnack to typed ...

And the you could get rid of SpecialInformation::DCOP altogether. The Browser would directly call the Widget::functions method to get the supported methods. All typed and everything.

What do you think?

cu

Fabian

PS: Eric, if you remember me. We had shared rooms in aKademy in Germany, Ludwigsburg ;-).
-- 
GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist!
NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl