[prev in list] [next in list] [prev in thread] [next in thread]
List: kdevelop-devel
Subject: interface names [Was: on documentation]
From: Aleix Pol <aleixpol () kde ! org>
Date: 2009-02-01 1:01:03
Message-ID: 757d9a550901311701u303539a7g2b864512bcac9eef () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I have seen we can use: <classname>_iid, it is actually defined by
KDEV_DECLARE_EXTENSION_INTERFACE_NS, so we don't need another one...
On Sat, Jan 31, 2009 at 11:37 PM, Andreas Pakulat <apaku@gmx.de> wrote:
> On 31.01.09 17:31:00, David nolden wrote:
> > Am Samstag 31 Januar 2009 17:13:56 schrieb Aleix Pol:
> > > hi list!
> > >
> > > I was thinking on kdevelop 4's documentation support. I've been
> checking
> > > some of the code we have in playground. It is quite disappointing to
> see
> > > that much of the code there is just oriented to support many many
> > > documentation formats but real actual integration.
> > >
> > > I think it would be nice to have proper integration support. For now
> > > doxygen and qt assistant would be nice, or maybe just assistant (since
> most
> > > of it could be used by getting it from Qt's assistant, QHelpEngine).
> > >
> > > What I think it would be important would be that this documentation
> support
> > > could be (easily) integrated with the DUChain. That would mean to be
> able
> > > to identify classes and method names and relate them to the proper
> > > documentation pages and show c++ reference if using c++ and Qt, and
> pyqt's
> > > doc if using python.
> > >
> > > What do you think about it? Is there any work to do so already done?
> > >
> > > Thanks,
> > > Aleix
> >
> > I think the first most important thing is, as you say, integration with
> the
> > duchain.
> >
> > For the start, we could just have something like this:
> > class IDocumentation : public KShared, public QObject {
> > //Should return a short version of the documentation
> > virtual QString html() = 0;
> > virtual KSharedPtr<IDocumentation> executeLink(QString link);
> > //Should open this documentation within an own part within KDevelop
> > virtual void showSeparateDocumentation();
> > Q_SIGNALS:
> > //Can be usd to signalize that new documentation is available(maybe
> downloaded
> > from the internet)
> > void documentationFetched();
> > };
> >
> > class IDocumentationPlugin {
> > //Should return 0 if no documentation for the declaration is available
> from
> > this plugin
> > virtual KSharedPtr<IDocumentation>
> > documentationForDeclaration(KDevelop::Declaration* declaration) = 0;
> > };
>
> I'd rather have s/Plugin/Support/ here and IMHO a static getter isn't
> really needed.
>
> On a related note: What we might want to do however is start putting the
> interface id's (i.e. org.kdevelop.IFoo) into static const strings
> accessible in the interface class. I know that IProjectFileManager is
> used in at least two different places in kdevplatform.
>
> Andreas
>
> --
> Don't you wish you had more energy... or less ambition?
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel@kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
[Attachment #5 (text/html)]
I have seen we can use: <classname>_iid, it is actually defined by \
KDEV_DECLARE_EXTENSION_INTERFACE_NS, so we don't need another one...<br><br><div \
class="gmail_quote">On Sat, Jan 31, 2009 at 11:37 PM, Andreas Pakulat <span \
dir="ltr"><<a href="mailto:apaku@gmx.de">apaku@gmx.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;"><div class="Ih2E3d">On 31.01.09 \
17:31:00, David nolden wrote:<br> > Am Samstag 31 Januar 2009 17:13:56 schrieb \
Aleix Pol:<br> </div><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><div class="Ih2E3d">> 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>
</div>I'd rather have s/Plugin/Support/ here and IMHO a static getter \
isn't<br> really needed.<br>
<br>
On a related note: What we might want to do however is start putting the<br>
interface id's (i.e. org.kdevelop.IFoo) into static const strings<br>
accessible in the interface class. I know that IProjectFileManager is<br>
used in at least two different places in kdevplatform.<br>
<br>
Andreas<br>
<font color="#888888"><br>
--<br>
Don't you wish you had more energy... or less ambition?<br>
</font><div><div></div><div class="Wj3C7c"><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>
</div></div></blockquote></div><br>
_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic