Qt Quick Controls (Former Qt Desktop Components)
This project aims to deliver Qt Quick components relevant to desktop developers. This includes things like layouts, menus and styling.
IRC channel: #qt-components on irc.freenode.org
The project focus is to get the current components set working as well as possible for the Qt 5.1 release.
Source Code Access
- git clone ssh://<username>@codereview.qt-project.org:29418/qt/qtquickcontrols.git
Use the “stable” branch and compile against a recent build of Qt 5.1 (qt “stable” branch)
Gitorious mirror: http://qt.gitorious.org/qt/qtquickcontrols
Use bugreports.qt-project.org [bugreports.qt-project.org], Project “Qt”, Component “QtQuick: Controls” or “QtQuick: Layouts”.
Filter [bugreports.qt-project.org] for viewing all unresolved bugs.
The components rely on several C++ plugins in order to integrate with the desktop. To install the
components into your Qt directory, simply enter the root directory and do:
- make install
This will compile and copy the plugins and components into your QTDIR/qml folder.
If you are compiling against a system Qt on linux, you might have to do a ‘sudo make install’
in order to install the project.
The examples should show how you can use the components.
There is a video demonstration available at http://www.youtube.com/watch?v=Y1pqL5bXe0A
If you are using the QtQuick 2.0 wizard in Qt Creator there are two issues you should be aware of: – you cannot have a Window (or ApplicationWindow) as the root item. To do this, you need to change your QtQuickView into a QtQmlEngine since Window is not a QtQuickItem. – You have to change QGuiApplication to a QApplication. This is because the components rely on certain widget-specific classes such as QStyle to do native rendering.
API Development Process Ideas
- Process to happen on mailing list (subscribe here: http://lists.qt-project.org/mailman/listinfo/qt-components ).
- When making API proposal/change always include: API definition and real world example (from a developer standpoint).
- Once decided upon an API proposal/change documentation has to be written right away.
- Enforcing a timeline around API discussion: from start of API definition to decision on it: 1 week.
- Making sure that at least one representant of each interested platform validates the API (if possible).
- Try to follow Qt naming convention if unsure.
- In case of unresolvable conflict of opinions, an appointed maintainer will have the last word.