Offer KF5 Libraries in the runtime

[sowelipililimute]

There are a few KDE frameworks that are beneficial to have when constructing QtQuick apps:

• Kirigami
  • Easy and idiomatic navigation handling
  • Tons of prebuilt components offering common patterns
  • Convergent applications
• KItemModels
  • KSortFilterProxyModel; a QML-usable proxy model for sorting and filtering items

Both of these only depend on Qt, so packing them in the runtimes should be fairly straightforward.

The biggest question is how to integrate these into the build system as they'll need to be compiled as part of the build process for all three supported platforms.

[pauldotknopf]

Would these projects need additional PInvoke stuff? Or, would they be used entirely within QML?

[sowelipililimute]

Would these projects need additional PInvoke stuff? Or, would they be used entirely within QML?

Both of these are used primarily purely from QML.

[pauldotknopf]

primarily

Let me ask it this way, would you ever need PInvoke?

[sowelipililimute]

No.

[pauldotknopf]

Can I ask, what are your plans? What are you looking to develop? How will you be deploying?

The reason why I ask, is because there is two ways of using this Qml.Net, managed and unmanaged hosting (see here).

I'd recommend unmanaged hosting for your more advanced scenarios:

• Compile against Qt, however you like. Maybe compile against the default packages/runtime in ubuntu:focal? debian:buster? etc.
• Bake in your own plugins/libs (as you are recommending here).
• Easier debugging. You can include Qml.Net into your qmake project with a simple pri include.
• Complete access to C++/Qt, considering main.cpp is the entry point.

The managed hosting is more geared for simple apps, or trying out Qml.Net. Typical Qt apps would need to access something that Qml.Net doesn't wrap/expose, for example, translations, or networking, etc.

[sowelipililimute]

Can I ask, what are your plans? What are you looking to develop? How will you be deploying?

I'm using Qml.Net to develop Staccato, a chat application.

The reason why I ask, is because there is two ways of using this Qml.Net, managed and unmanaged hosting (see here).

I'd recommend unmanaged hosting for your more advanced scenarios:

• Compile against Qt, however you like. Maybe compile against the default packages/runtime in ubuntu:focal? debian:buster? etc.
• Bake in your own plugins/libs (as you are recommending here).
• Easier debugging. You can include Qml.Net into your qmake project with a simple pri include.
• Complete access to C++/Qt, considering main.cpp is the entry point.

The managed hosting is more geared for simple apps, or trying out Qml.Net. Typical Qt apps would need to access something that Qml.Net doesn't wrap/expose, for example, translations, or networking, etc.

Managed hosting is somewhat problematic for my usecase as

1. The KF use CMake, not qmake. It's preferred to use CMake over the not well maintained qmake shims. Having the QtQuick plugins available in the runtime for import-ing would be preferable to mucking with static linking.
2. I'm not particularly interested in writing C++ glue: all I care about is exposing data to QML backed by C#.
3. Lack of integration with dotnet tooling isn't appealing; especially since the project I'm working on uses MSBuild to manage stuff like grpc/protobuf code.

[pauldotknopf]

Managed hosting is somewhat problematic for my usecase as

I think you mean unmanaged hosting.

The KF use CMake, not qmake. It's preferred to use CMake over the not well maintained qmake shims. Having the QtQuick plugins available in the runtime for import-ing would be preferable to mucking with static linking.

I think QmlNet.pro could be expanded to also have a CMakeList.txt alternative. At this point, you wouldn't be dealing with anything that any other deployed Qt apps wouldn't experience as well.

I'm not particularly interested in writing C++ glue: all I care about is exposing data to QML backed by C#.

Fair enough.

Lack of integration with dotnet tooling isn't appealing; especially since the project I'm working on uses MSBuild to manage stuff like grpc/protobuf code.

You'd still have the tooling. The unmanaged hosting option requires you to have a console app that serves as the entry point to the .NET runtime. This console app is build with the dotnet command.

With that said, I'm open to adding those libs into the default runtimes. However, that will will be a little involved.

We'd have to update this repo to have travis/appveyor builds that do the compilation, and publish the runtimes somewhere.

[sowelipililimute]

Managed hosting is somewhat problematic for my usecase as

I think you mean unmanaged hosting.

Yep, mb.

-snip-

With that said, I'm open to adding those libs into the default runtimes. However, that will will be a little involved.

We'd have to update this repo to have travis/appveyor builds that do the compilation, and publish the runtimes somewhere.

As for the build system itself?

I can't really see how you'd add the compile/install KF5 steps into the build system as it currently is.