Bug 547594 – Consider unifying declarative and qml USE flags

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description Davide Pesavento (RETIRED) 2015-04-24 16:08:56 UTC]

Currently we have

dev-python/PyQt4:declarative - Build bindings for the QtDeclarative module
dev-python/PyQt5:declarative - Build bindings for the QtQml/QtQuick modules and enable the qmlscene plugin
dev-python/pyside:declarative - Build QtDeclarative module
dev-qt/designer:declarative - Build the qdeclarativeview plugin
dev-qt/qtdemo:declarative - Build QtDeclarative examples and demos
kde-base/perlqt:declarative - Compile bindings for dev-qt/qtdeclarative.
kde-base/qtruby:declarative - Compile bindings for dev-qt/qtdeclarative.
kde-base/smokeqt:declarative - Compile bindings for dev-qt/qtdeclarative.

dev-qt/linguist-tools:qml - Enable QML support in lupdate
dev-qt/qt-mobility:qml - Build QML bindings
dev-qt/qtmultimedia:qml - Build QML/QtQuick bindings and imports
dev-qt/qtpositioning:qml - Build QML bindings
dev-qt/qtsensors:qml - Build QML bindings
dev-qt/qtwayland:qml - Build QML/QtQuick bindings
dev-qt/qtwebkit:qml - Build QML/QtQuick bindings
dev-qt/qtwebsockets:qml - Build QML bindings
net-im/qutim:qml - Enable QtQuick-based chat plugin

It's not clear to me what's difference between the two flags, if any. In any case we package QtQml and QtQuick together in dev-qt/qtdeclarative, splitting them is very hard (if not impossible), so there's no point in distinguishing between the two, they will both pull in qtdeclarative.

We should pick one name for the flag and change all packages to use it. Possibly also make it global.

[Comment 1 Davide Pesavento (RETIRED) 2015-04-24 16:23:39 UTC]

Some options...

*) declarative: clear reference to the package name, and name of the upstream git repo, could be confusing in qt5 land because QtDeclarative is the name of the compat module that offers the old qt4 declarative APIs to qt5 applications.

*) qml: short :) also should be more familiar to qt developers because QtQml is the name of the module visible to them (header files and "QT += qml" in .pro files), however it's only one of the modules contained in qtdeclarative:5.

*) quick/qtquick: QtQuick is the "marketing" name of the technology, so regular users might be more familiar with it, but has the same problem of "qml", it's only one of the qtdeclarative modules. "quick" is probably too generic, "qtquick" is somewhat better.

[Comment 2 Michael Palimaka (kensington) 2015-04-24 16:44:29 UTC]

I agree, with no particular choice preference. It would be nice to avoid the declarative confusion though, that keeps cropping up from time to time.

[Comment 3 Davide Pesavento (RETIRED) 2015-04-24 16:45:47 UTC]

What causes confusion exactly?

[Comment 4 Michael Palimaka (kensington) 2015-04-24 18:08:19 UTC]

The declarative naming discrepancy. Even outside Gentoo I've seen a few times people getting confused that declarative package doesn't give you declarative module.

[Comment 5 Andreas Sturmlechner 2022-04-02 11:31:01 UTC]

Should we pursue this further?

[Comment 6 Ionen Wolkens 2023-09-05 15:57:56 UTC]

(In reply to Andreas Sturmlechner from comment #5)
> Should we pursue this further?
I think not, we only have 3 packages left with IUSE=declarative (PyQt5, designer, and qt-docs)

Renaming on PyQt5 would be rather disruptive both for users and dependencies (in overlays too, some extensively use PyQt5), and I think is not worth it (PyQt6 is already using qml)

qt-docs is docs for the declarative package itself so maybe it makes enough sense.

designer could be renamed anytime I guess, albeit may still disrupt a few users

Overall think Idea is just to stick to qml going forward, maybe not the best choice but it's short and has become fairly consistent.