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
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
