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

[Fabian Franz]

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

Great! That is it. Thank you.

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

As its not necessary, I won't do this, but it should be documented on the plugins page that they only run properly with the new parser.

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

As far as I know kommander searched for a possibility to be able to use almost all widgets directly in kommander.

Okay, I have now created a plugin, which implements a widget, which ships its own DCOP code (additionally to registering with the SpecialInformation Interface)

http://studwww.ira.uka.de/~s_franz2/fsmi-deluxe-plugin-0.1.tar.gz

works quite great.

And generally this could be used like:

DCOPQuery()
{
   prepareDataStream

   if (localWidget)
       localWidget->process(dataStream);
   else
       myDcopClient->call(appId, WidgetName, dataStream);

   prepareReturnValue
}

The only culprit I have is that its not enough to just put the method in dcop*if.h it still has to be implemented by the base class, which possibly just runs QTable::theMethod or QLineEdit::theMethod ...

However this could be automatised of course and needs just to be done once.

I think with just little work it might be possible to export all trivial (e.g. using the common types) public member functions of for example QTable via DCOP.

To talk about backwards compatibility of the old KommanderIf.

The DCOP:process functions of instance.cpp would then look like:

- Check that the executed function is valid.
- Get the widgets Name
- Find the widget
- Remove widgetName from dataStream
- widget->process(dataStream)

And as I've already said all information that SpecialInformation had saved before can now be gotten from:

widgetName->functions()

It could even be double-cached in SpecialInformation.

Tell me what you think.

cu

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