Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 547594 - Consider unifying declarative and qml USE flags
Summary: Consider unifying declarative and qml USE flags
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Qt Bug Alias
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-24 16:08 UTC by Davide Pesavento
Modified: 2023-09-05 15:57 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Davide Pesavento (RETIRED) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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) gentoo-dev 2015-04-24 16:45:47 UTC
What causes confusion exactly?
Comment 4 Michael Palimaka (kensington) gentoo-dev 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 gentoo-dev 2022-04-02 11:31:01 UTC
Should we pursue this further?
Comment 6 Ionen Wolkens gentoo-dev 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.