QtDesktopComponents

From Qt Wiki
Jump to: navigation, search

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

Scope

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.io: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

Bug Tracking

Use bugreports.qt.io, Project "Qt", Component "QtQuick: Controls" or "QtQuick: Layouts".

Filter for viewing all unresolved bugs.

Installation

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:

qmake
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.

Usage

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.io/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.

Blogs entries