Add support for nested JavaScript-Code documentation

[chrpetzold]

When i use QML code i would like to have doxygen documentation for nested JavaScript code, too. Considder this example:

Component {
    id: myId

    /** This doxyqml comment will be found by doxyqml */
    property var someProperty

    /** 
     * @brief outputs "test" in console, this is not detected by doxyqml?
     */
    function myJavaScriptFunction() {
        console.log("test");
    }
}

Maybe i do not understand some thing right or i missed something in the doxygen configuration. Thank you for doxyqml :)

[agateau]

This works correctly for me. Can you provide a minimal source set to reproduce the issue (ie, a .qml and a Doxyfile)?

[agateau]

One thing I noticed while testing though is that Doxygen 1.8.8 requires this new entry in the configuration file:

 EXTENSION_MAPPING = qml=C++

Otherwise the output of doxyqml is ignored.

[chrpetzold]

Thank you for the kind response. I will check my doxygen configuration file for the configuration
EXTENSION_MAPPING = qml=C++
I do not have access to my workspace at the moment but i think i will be able to give you feedback and/or a minimal example source on thursday.

[chrpetzold]

It turns out that i have not correctly described my problem. My first stated example works well for me, too. I forgot the "nested" part in that example. So here is the real example which is not working for me:

import QtQuick 2.3
import QtQuick.Controls 1.2

ApplicationWindow {
    id: myApplicationWindow
    visible: true
    width: 640
    height: 480
    color: "lightblue"
    /**
     * my documentation will be visible in the doxygen output
     */
    function myPublicFunction ()
    {
    }

    Rectangle {
        id: myRect
        width: parent.width / 2
        height: parent.width / 2
        anchors.centerIn: parent
        /**
         * my documentation will not be visible in the doxygen output
         */
        function myNestedFunction ()
        {
        }
    }
}

I have experimented with

EXTENSION_MAPPING = qml=C++
EXTENSION_MAPPING = qml=Javascript
EXTENSION_MAPPING = 
EXTRACT_ALL = Yes
EXTRACT_PRIVATE = Yes

which all makes no difference to me. Maybe the "myNestedFunction" documentation is not found by design and it would be better programming style to source out internal components into destinct files anyway.
I have uploaded a minimal project to:
https://www.dropbox.com/s/w4wkibvdprlyj89/MinimalDoxyQMLExample.zip?dl=1

doxygen 1.8.7, python 2.7, doxyqml 0.2.0

[agateau]

(Sorry, I totally missed the notification about your answer)

Unfortunately I don't work with QML these days, so I don't have time to work on this, would you be interested in working on it? On the other hand, as you said, nested code is not really meant to be used by the outside world, so I am not sure whether this is really a problem. What do you think?

[mpaperno]

Perhaps nested doxy comments (and associated code bits) could be extracted and put in the base class. From there one could control the output with \group, \internal, or whatever. Or not use doxy comments in the first place. Of course one could do that manually now, the main attraction here is keeping docs close(r) to the code. OTOH it would be a behavior change (quite a big one) so probably also needs to be some kind of option to enable it.

[mlam19]

I've tried modifying Doxyqml to document nested components with IDs, and attributes. Nested components appear as private variables of the type of the component within the top level class/component. The type of the component becomes a nested class within the top level class/component. Attributes also appear as private variables.

I did not replicate the nested structure of the QML in the documentation to make the end documentation easier to read and navigate.

There are also things that I have not translated well into C++, like attributes with names like "something.something".

https://github.com/mlam19/doxyqml/tree/children

[agateau]

Hi @mlam19, the output of your branch looks promising! would be great if you could clean it up a bit (*) and file a pull request.

(*) by clean it up I mean: not using camelCase for variables, reducing the amount of empty lines and not reindenting the test files (making it easier to see the changes you made)