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

[Eric Laffoon]

On Thursday 09 November 2006 5:39 am, Fabian Franz wrote:
> > > @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.

No problem. In the widget or script where you use it set a Kommander shebang.
#!kommander
see http://kommander.kdewebdev.org/parser/invoking.html
In this way you can use both parsers. Also if you are using the latest release 
of Kommander you can share globals between them.
>
> > > 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?

Probably.
>
> 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'll leave this for Michal, but suffice it to say we are doing some unusual 
things and extensively managing DCOP so if you're talking using autogenerated 
with IDL I don't think that's a likely option.
>
> 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?

I'm half asleep and overworked... I'd like Michal to look. The special 
information also is used for the function browser and externally creating 
function catalogs, documentation, etc... It's not like it's something we're 
looking to dump. At the same time we are looking for developer input, ideas 
and code review.
>
> cu
>
> Fabian
>
> PS: Eric, if you remember me. We had shared rooms in aKademy in Germany,
> Ludwigsburg ;-).

Actually Michal was in that room too... and don't worry we won't hold it 
against you. ;-)
-- 
Eric Laffoon
Project Lead - kdewebdev module