Bug 2227098

If I build with -DKDDockWidgets_QTQUICK=true files will replace ordinary Qt5 build.
Will with build still compatible with ordinary QtWidgets?

Hmmm, actually I do not know.  From src/CMakeLists.txt I can see that different header files are installed in the 2 cases, so I guess it is not completely compatible.  It's too bad upstream didn't write their software so a single library could choose either QtWidgets or QtQuick.

If MuseScore is the only application that wants the QtQuick version, then we can let it continue to bundle KDDockWidgets rather than making you do a lot of work.

Reading through that same src/CMakeLists.txt, I don't see any issue enabling both KDDW_FRONTEND_QTWIDGETS and KDDW_FRONTEND_QTQUICK in the same build.

Yes, there are sections wrapped in:

if(KDDW_FRONTEND_QTWIDGETS)

and others wrapped in:

if(KDDW_FRONTEND_QTQUICK)

but those sections are never elif()'d, and if both are true then the union of their respective filesets will be installed.

In fact, the correct way to enable both frontends (at least in the current 1.7.0 source) seems to be:

cmake ... -DKDDockWidgets_FRONTENDS="qtwidgets;qtquick"

That will activate all of KDDW_FRONTEND_QT, KDDW_FRONTEND_QTWIDGETS and KDDW_FRONTEND_QTQUICK, and ensure that all of the appropriate files will be built and installed.

The only mutually exclusive frontends are QT (either one) and FLUTTER. The root CMakeLists.txt will abort with a FATAL_ERROR if KDDW_FRONTEND_QT and KDDW_FRONTEND_FLUTTER are both TRUE (caused by "flutter" and either "qtwidgets" or "qtquick" both appearing in the KDDockWidgets_FRONTENDS list).

I'll put together a PR for activating the QtQuick frontend alongside QtWidgets in the 1.7.0 build.

(In reply to "FeRD" (Frank Dana) from comment #3)
> those sections are never elif()'d

elseif()'d. (It's CMake, not Python.)

Aha! However, there _is_ this note in the README.md:

⚠️⚠️: If you're using QtQuick/QML it's recommended to use 2.0 branch. 1.x will continue to receive bug fixes for a long time but only for QtWidgets frontend.

So, if we take that seriously, really the package should be kddockwidgets v2.0.0-beta1 (which is the code I was actually reading, not 1.7.0, as 2.0 is now the default branch for https://github.com/KDAB/KDDockWidgets), rather than kddockwidgets 1.7.0.

Reading through the 1.7.0 CMakeLists.txt, I do see that -DKDDockWidgets_QTQUICK is documented as selecting to "Build for QtQuick INSTEAD OF QtWidgets." (Emphasis added.) So, this is only solved in the beta 2.0 sources. Apologies for not catching that initially.

So we are waiting for release 2.0.0?

Well, the README was actually just updated, it now starts off:

"It's recommended to start using the 2.0 branch, which should already be as stable as v1.7 but with more features."

And later:

"Use 2.0 if you need non-QtWidgets support, for example QtQuick/QML. While 1.7 has support for QtQuick/QML it won't be receiving bug fixes. 2.0 is under active development, you might encounter minor source/ABI incompatibilities. Despite that, it is pretty stable, and all 200 unit-tests pass."

So IMHO, it wouldn't be insane to package up 2.0, either from the git HEAD of the 2.0 branch, or from the beta1 tag that was created in August: https://github.com/KDAB/KDDockWidgets/releases/tag/v2.0.0-beta1

...At least in rawhide. But, that's purely my personal opinion. I'm not the one who has to support it.

(In reply to Jerry James from comment #0)
> MuseScore 4.x bundles KDDockWidgets.  I would like to unbundle it, but
> MuseScore requires a Qt5 build with -DKDDockWidgets_QTQUICK=true.  

Do you know if the MuseScore code is compatible with KDDockWidgets 2.0, by any chance?

I filed bug 2297298 the other day in which I raised the possibility of creating a separate kddockwidgets2 Fedora package, since the 2.0+ releases are breaking changes from 1.7.0 so just forcibly updating the existing 1.7.0 users to 2.0+ would break their code.

But as discussed, 2.0+ has the advantage that it can be built for QtWidgets _and_ QtQuick (in the same build), instead of it being a binary choice of one or the other.

So, the easiest path would be to have MuseScore pick up a theoretical kddockwidgets2-qt5 package as a dependency, to replace the bundled KDDockWidgets... but that only works if the code is compatible with 2.0. (Or 2.1, actually, as that's now been released. But it doesn't contain any API breaks from 2.0.)

In the current MuseScore release, the bundled version is 1.5.0, not even 1.7.0.  I don't know for sure, but I would guess that it is probably not compatible.  If you make a 2.1 build somewhere, such as a COPR, let me know and I will see if I can port MuseScore to work on it.

(In reply to Jerry James from comment #9)
> In the current MuseScore release, the bundled version is 1.5.0, not even
> 1.7.0.  I don't know for sure, but I would guess that it is probably not
> compatible.  If you make a 2.1 build somewhere, such as a COPR, let me know
> and I will see if I can port MuseScore to work on it.

Oh, that's a good idea! I've created a ferdnyc/kddockwidgets2 COPR for builds of 2.1.0. All of the rawhide builds failed due to some apparent const-correctness issues in the rawhide version of fmt-devel (and the package's use of -Werror in the build), but the F40 builds succeeded. (Some are still waiting on fedora-review, which I perhaps-foolishly enabled not realizing how SLOW it apparently is. But the package builds are already done, for all supported arches.)

Both kddockwidgets2 and kddockwidgets2-qt6 are installable side-by-side with the official kddockwidgets-1.7.0 builds. The -devel packages will conflict, though, due to the clashing library name (unversioned libkddockwidgets.so), include path, and CMake configuration directories, so I've marked them as such in the package metadata. You'll have to uninstall kddockwidgets-devel and kddockwidgets-qt6-devel in order to install kddockwidgets2-devel and kddockwidgets2-qt6-devel.

...And after realizing I'd completely screwed up the Conflicts: tags, I rebuilt them.

But I also took a look at MuseScore's code.

I don't see any way of unbundling their use of KDDockWidgets to use a system install. They're including _private_ headers from the source tree that don't even get installed, so they wouldn't be available in /usr/include/kddockwidgets/ ... no matter WHAT version, and no matter HOW it's built.

(See, for example, the includes in this file:)

https://github.com/musescore/MuseScore/blob/6d843753e8e22347be32ffaaabfd0388c43d2a78/src/framework/dockwindow/dockmodule.cpp#L45-L48

Actually, I should walk that back a little. Those private headers **are** installed, in KDDockWidgets 1.7, but they no longer exist in 2.1. So, while the paths are different, they could theoretically be adjusted to use a system install of KDDockWidgets 1. But there are indeed code changes that would be required to make it compatible with 2.0, apparently.

(In reply to "FeRD" (Frank Dana) from comment #12)
> Actually, I should walk that back a little. Those private headers **are**
> installed, in KDDockWidgets 1.7, but they no longer exist in 2.1. So, while
> the paths are different, they could theoretically be adjusted to use a
> system install of KDDockWidgets 1. But there are indeed code changes that
> would be required to make it compatible with 2.0, apparently.

Revisiting this, with version 2.4.0: Is that something you still would like to be implemented? As long as it doesn't replace the original libraries, I can simply add the qtquick libraries in. And do you still want Qt5, or should we do Qt6 instead? Let me know.

The latest release of MuseScore now uses Qt6 instead of Qt5, but it is still stuck on KDDockWidgets 1.5, with patches to make it work with Qt6.  I think you should do whatever is best for the KDDockWidgets package and not worry about MuseScore for now.  If upstream someday manages to migrate to KDDockWidgets 2.x, then we can see if anything needs to be done to unbundle at that point.