QtDesktopComponents

From Qt Wiki
Jump to navigation Jump to 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