QML support in kde.org services
Stephen Kelly
steveire at gmail.com
Mon Sep 5 14:14:01 BST 2011
Albert Astals Cid wrote:
> A Diumenge, 4 de setembre de 2011, Stephen Kelly vàreu escriure:
>> Harald Sitter wrote:
>> > On Sun, Sep 4, 2011 at 2:18 PM, Stefan Majewsky
>> >
>> > <stefan.majewsky at googlemail.com> wrote:
>> >> 2. api.kde.org doesn't show QML elements.
>> >
>> > Problem with this is that Doxygen does not support QML (yet anyway),
>> > actually I would not know how to make this work in a sane manner
>> > considering that plenty of QML elements will be directly based of a
>> > CPP object... (in phonon we actually have the documentation in the cpp
>> > object which implements the element).
>> > So, doing this in a meaningful way would likely require using qdoc for
>> > QML element documentation.
>>
>> I think that's something we should consider for kf5 anyway, for the same
>> reason. qdoc is more free now than when doxygen was created, though it
>> might not have all useful features of doxygen. Those might need to be
>> added.
>
> What is the point of trying to improve the "worse" of the two options?
>
> Albert
I have no idea which is worse. I don't know what qdoc is missing.
However, Doxygen doesn't support QML. So we can do one of the following:
* Investigate, then add QML support to doxygen.
* Don't investigate. Add QML support to doxygen or file a bug report about
it.
* Investigate, see what is missing/different in qdoc (which already has QML
handling), add it and use that.
* Ignore the issue, not investigate it, and maybe write a blog post about
how doxygen sucks because it doesn't support QML. Then maybe Dimitry will
add it.
My searches here didn't show up anything about QML:
https://bugzilla.gnome.org/query.cgi?format=advanced;product=doxygen
Nokia is eventually going to realize that their customers want to document
QML stuff, and will need to either add the feature to doxygen and continue
recommending doxygen as they currently do, or they will make qdoc more
useful.
Yes, there are many reasons to stick with doxygen (we have the scripts and
infrastructure using it etc). I'm saying we have an opportunity to see what
else there is and we can choose to use that opportunity.
Thanks,
Steve.
More information about the kde-core-devel
mailing list