[Development] Extending moc to generate easily accessible metatype descriptions

[Holland, Dominik (Pelagicore)]

While we are already at improving plugins.qmltypes, maybe we could also
enhance it a bit more and also provide a qmltypes files for all Qt basic
types and enhance the format to also allow the definition for global
objects e.g. the Qt object and its functions, which currently don't
provide any auto-completion ?

And also provide completion for the return values of functions ?

Dominik

Am 17.09.19 um 08:55 schrieb Ulf Hermann:
>> Well, unfortunetely, even moc doesn't know about all the metatypes.
>> Many types don't need registration, and moc is not always aware of the 
>> Q_DECLARE_METATYPE declaration (but it actually should still work for 
>> most types)
>>
>> There are also all the custom QMetaObject (thinking of stuff like DBus, 
>> ActiveQt or other language bindings, or the ones created by Verdigris)
> We can add something like the QML_FOREIGN declarations introduced in 
> https://codereview.qt-project.org/c/qt/qtdeclarative/+/248475 on the 
> metaobject level. A dummy struct with some macros that would tell moc 
> "there is a metaobject you cannot see and it has these properties".
>
> Or we can live with the fact that we don't have all metatypes in the 
> json files. If you want your types to appear there you have to follow 
> some conventions.
>
>> But this post-processing of the .json files is not necessarily something 
>> for moc. It could be in a separate tool.  (But I realize that you can 
>> just add the option to the moc binary to avoid creating another small 
>> tool just for that.)
> Yes, I can move it into an extra tool if necessary, but as that is still 
> part of some kind of "meta object compilation" and it's not a lot of 
> code, I would actually prefer to keep it inside moc.
>
>> The question is also how does it fits in the build system? How do you 
>> know which .json to collect and at what stage do you do that?
> moc already creates a number of files called moc_<foo>.cpp. The build 
> system has to deal with that already. Now it also creates files 
> moc_<foo>.cpp.json. The handling of those should be equivalent on a 
> build system level. The way it's done in qmake right now is that we 
> create a fake rule for the json file that depends on the moc rule but 
> doesn't do anything by itself. It just declares that it "creates" the 
> json file. I'm sure you can phrase something similar in other build systems.
>
>> Is this going to add some burden for people using custom build systems?
> You can either ignore it and live without automatic generation of 
> qmltypes files (and automatic registration of QML types, see 
> https://codereview.qt-project.org/c/qt/qtdeclarative/+/271876 for a 
> rough sketch), or you can adapt your build system. So, either you keep 
> the burden you already have, or you replace it with a different and 
> hopefully smaller one. The trade-off depends on the properties of your 
> build system.
>
>> And how mandatory will it be?  Is it ok if this does not work?
> If it doesn't work you have to write your qmltypes files manually or use 
> qmlplugindump (although I would like to deprecate the latter, eventually).
>
>> Also I would need to find a solution for Verdigris.  (Was thinking about 
>> generating the json at compile time in a constexpr string put in a 
>> specific section of the binary,  but how does it ends up in a qmltypes 
>> then?)
> That sounds like a good idea. We can probably write a qmltyperegistrar 
> variant that pulls its input from some ELF section instead of a separate 
> json file.
>
> br,
> Ulf
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development