[umbrello-devel] QtModeling and Umbrello

[Ralf Habacker]

Am 13.08.2015 um 19:55 schrieb Sandro Andrade:
> On Thu, Aug 13, 2015 at 10:16 AM, Ralf Habacker <ralf at habacker.de> wrote:
>> Am 13.08.2015 um 11:33 schrieb Ralf Habacker:
>>
>> /home/qt/src/qtmodeling/src/modeling/qmodelingobject_p.h:45:31: fatal error:
>> private/qobject_p.h: No such file or directory
>>
>> #include "private/qobject_p.h"
>>
>> Got it - qtmodeling requires private headers from qt which are supported on
>> opensuse by the 'libqt5-qtbase-private-headers-devel' package. For Windows
>> there is currently no such package available.
>>
>> Because qtmodeling depends on qt internals it is required to recompile
>> qtmodeling with every new qt release, which increases required support.
> Yes, that's because it extends some features from QObject. KF5 also requires
> qt's private headers. Getting rid of that would imply in some undesired overhead
> when creating private classes in pimpl implementations.
>
>> Also it looks that there are no public binary packages (at least on
>> opensuse), which makes distribution builds.more complicated.
> I used to be some QtModeling packages being created in OBS. I can
> bring they back if you find it useful.
It is possible to embed Qtmodeling source into a client application like
it has been done with the KDevelop's c++ parser (see lib subdir in
umbrello source tree
https://projects.kde.org/projects/kde/kdesdk/umbrello/repository), but
in the case of QtModeling this is ineffective, because is would require
to recompile the umbrello binary package every time the version of Qt
changes or on simple QTModeling bug fixes.

> Sandro says it could be used by Umbrello as well as for example Qt
Creator or KDevelop.
Also embedding QtModeling source in more than one client package is not
efficient for the reasons mentioned above. In fact a dedicated
QtModeling package is mandatory.

Cheers
Ralf