IDocumentation::documentationWidget

Andreas Pakulat apaku at gmx.de
Sun Aug 22 19:49:04 UTC 2010


On 22.08.10 21:33:12, Aleix Pol wrote:
> On Sun, Aug 22, 2010 at 9:20 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> > On 22.08.10 19:51:43, Aleix Pol wrote:
> > > Well, it is disabled by default so if the documentation provider is not
> > > interested on supporting search he will find it disabled.
> > >
> > > I can improve the documentation if you consider necessary, just tell me
> > what
> > > is what you're missing. :)
> >
> > IMHO David is right, if a idocumentation should provide some kind of
> > find-widget there should be a separate virtual function to retrieve that
> > and that function should return 0 by default.
> 
> Erm.. no, it's not how it works, the thing is that when we provide the
> documentation widget we get a find widget argument that we can use to pass
> and decide if it will be supported (by enabling the widget) and to connect
> to the signals it provides if necessary. I'm planning to provide more
> options there, like making it possible to customize some actions inside the
> find widget from the provider but it's not added yet.

So the API is even misleading. IMHO if you want a documentation plugin
to be able to tell the toolview wether certain things should be
supported or not then the API needs a 'supportedXXX' function (or
multiple). The signal-connections can be easily done by using a virtual
in the API that is being called instead of the signal/slot connection.

I don't see how the provider would be able to customize the actions,
except by disconnecting them and re-connecting to its own slots, which
is no good API at all.

Andreas

-- 
Cheer Up!  Things are getting worse at a slower rate.




More information about the KDevelop-devel mailing list