Doxyqml, supporting type

[Aurélien Gâteau]

Le mardi 23 octobre 2012 00:23:25 Aleix Pol a écrit :
> I think you are great Aurélien :D

*blushes* :)
> 
> More seriously though, I think that a patch on some current code would
> be really helpful.

Sure. When this is deployed, I want to go through the current documentation 
and split it accordingly.

> Also did we consider how different will be C++ components vs. QML
> components? Ideally they should have a similar aspect since we'll
> likely be using them both together.

Agreed.

That reminds me of a problem I did not mention: some QML components are mostly 
empty, their API comes from their C++ base class, but Doxygen cannot show it 
because the C++ base class is not exposed with the same name on the QML side.

If this sounds confusing, here is an example:

ContextMenu.qml only contains this (stripping imports and comments):

    Menu {
        id: root
    }

It inherits from Menu, but looking at plasmacomponentsplugin.cpp, one finds 
this:

    qmlRegisterType<QMenuProxy>(uri, 0, 1, "Menu");

Doxygen has no chance of parsing this and cannot show the inherited 
properties, functions and methods.

That can be work-arounded by adding a "typedef QMenuProxy Menu;" to qmenu.h 
(QMenuProxy header file). With this typedef in, Doxygen shows the base class 
info, but it is still a bit ugly because the typedef gets resolved so 
ContextMenu is documented as inheriting from QMenuProxy, a class which is not 
accessible from the QML side.

I think we should rename C++ classes so that they use the same name on the C++ 
and QML sides.

> Code-wise, I don't think having a type: prefix is bad and given that
> the type can be any class name, it can be good to have it specified
> because it's easy to read it, if it starts with string but not so easy
> if it starts with e.g. TextField.

OK. I keep it this way then.

Aurélien