<br><br><div class="gmail_quote">On Sat, Jan 31, 2009 at 5:31 PM, David nolden <span dir="ltr"><<a href="mailto:david.nolden.kdevelop@art-master.de">david.nolden.kdevelop@art-master.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Am Samstag 31 Januar 2009 17:13:56 schrieb Aleix Pol:<br>
<div><div></div><div class="Wj3C7c">> hi list!<br>
><br>
> I was thinking on kdevelop 4's documentation support. I've been checking<br>
> some of the code we have in playground. It is quite disappointing to see<br>
> that much of the code there is just oriented to support many many<br>
> documentation formats but real actual integration.<br>
><br>
> I think it would be nice to have proper integration support. For now<br>
> doxygen and qt assistant would be nice, or maybe just assistant (since most<br>
> of it could be used by getting it from Qt's assistant, QHelpEngine).<br>
><br>
> What I think it would be important would be that this documentation support<br>
> could be (easily) integrated with the DUChain. That would mean to be able<br>
> to identify classes and method names and relate them to the proper<br>
> documentation pages and show c++ reference if using c++ and Qt, and pyqt's<br>
> doc if using python.<br>
><br>
> What do you think about it? Is there any work to do so already done?<br>
><br>
> Thanks,<br>
> Aleix<br>
<br>
</div></div>I think the first most important thing is, as you say, integration with the<br>
duchain.<br>
<br>
For the start, we could just have something like this:<br>
class IDocumentation : public KShared, public QObject {<br>
//Should return a short version of the documentation<br>
virtual QString html() = 0;<br>
virtual KSharedPtr<IDocumentation> executeLink(QString link);<br>
//Should open this documentation within an own part within KDevelop<br>
virtual void showSeparateDocumentation();<br>
Q_SIGNALS:<br>
//Can be usd to signalize that new documentation is available(maybe downloaded<br>
from the internet)<br>
void documentationFetched();<br>
};<br>
<br>
class IDocumentationPlugin {<br>
//Should return 0 if no documentation for the declaration is available from<br>
this plugin<br>
virtual KSharedPtr<IDocumentation><br>
documentationForDeclaration(KDevelop::Declaration* declaration) = 0;<br>
};<br>
<br>
Then we could start implementing different documentation-provider plugins one<br>
by one. The first one we really need is one for Qt, since Qt does not have any<br>
in-header comments. The main question is how to get the relevant information.<br>
<br>
The navigation-widgets could just query for all plugins implementing<br>
IDocumentationPlugin, and try getting documentation from them.<br>
<br>
Greetings, David<br>
<br>
<br>
_______________________________________________<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</blockquote></div><br>I'm wondering if this "executeLink" should be here.. Why don't simply let the part version to deal with the links?<br>