PROBLEM

as talked about recently, there are some issues with the current content & design of KF5's KDesignerPlugin module. Which currently provides:

• a utility (kgendesignerplugin) that can be used to generate plugins for Qt Designer from ini-style description files, e.g. by using the CMake macro kf5designerplugin_add_plugin()
• a single Qt Designer plugin for all the widgets in all the modules of KDE Frameworks

The issues with that single plugin are:

• defeats the idea of independent modules in KDE Frameworks, at least with Linux/*BSD distributions: the plugin has a dependency on all the modules whose widgets it sports
• is a separate module from the actual widget code, thus running chance of not getting updated in case widgets get extended/added/deprecated

The issues with the tool are:

• another separate tool to use, so appearing as yet another dependency item

Now while the big plan seems to replace QWidgets with Qt Quick Controls one day, so far QWidgets are still here with us and might be a bit more. So it makes sense to invest a bit to improve the situation.

WANTED

Required:

• each Frameworks module should be able to provide its own Qt Designer plugin for its widgets.
• Creating the plugin should be an optional build feature, so one can disable that if e.g. building library modules for app bundles, where one never will need the plugin.

Optional:

• does not create yet another dependency, even more for KDE Frameworks tier 1 modules.
• simple to port to from old kgendesignerplugin usage

PROPOSED SOLUTION

Given that

• CMake is the current standard build system generation tool with all libraries currently looked at where we want to have Qt Designer plugins for, and as of now nothing hints this will change soon
• ECM is used already by all libraries currently looked at
• CMake is able to be used for C++ code generation at configuration time, which is already made use of in ECM code
• the code generated for Qt Designer plugins is not that complicated
• part of the code for generating Qt Designer plugins is repeated CMake logic

an approach is to have another addition to ECM, named ECMAddQtDesignerPlugin, which does the generation of the plugin code directly.
Pro:

• kgendesignerplugin was already wrapped by CMake macro logic
• no additional dependency on external tool

Cons:

• only works with CMake

Writing CMake code for parsing the ini-format of the .widgets files for configuring kgendesignerplugin might have been complicated, so as alternative some declaration macro is used with a metadata describing pattern modelled after the one of the ini format, so conversion can be done by copy, paste and modify.

Current set of patches:

• Addition of the new ECM module: D22724
• Deprecation of KDesignerPlugin, drop of single cross-KF5 plugin D22784
• Own plugin for KWidgetsAddons: D22725
• Own plugin for KIO: D22785
• Own plugin for KIconThemes: D22790
• Own plugin for KTextWidgets: D22791
• Own plugin for KPlotting: D22792
• Own plugin for KCompletion: D22793
• Own plugin for Sonnet: D22794
• Own plugin for KItemViews: D22795
• Own plugin for KConfigWidgets: D22796
• Own plugin for KXmlGui: D22798
• Make KDEWebKit use ECMAddQtDesignerPlugin: D22777
• Restore option for KSysguard Library to create a Qt Designer plugin: D22778

There was also a patch done to port kdelibs4support (D22776), but turns out it installs a macro using kgendesignerplugin, so I turned away from changing code there. No need to complicate things for something people should port away from anyway,