• Qt needs to work out of the box for embedded boards without having to patch Qt and mkspecs over and over again
• Provide an optimal build for the device
• Focus is on cross-compilation and not on on-target compilation

Note: Most of the stuff below is already in qtbase. -device is currently marked as ‘experimental’

configure

• -device <device> specifies the device.
• Together with -sysroot and -device-option CROSS_COMPILE to specify the compiler, you will have Qt for your board!
  • For example, for the raspberry-pi, all one needs to do is:
    
    1.       configure -device pi -sysroot  -device-option CROSS_COMPILE=/xgcc/prefix
• There is mechanism to pass arbitrary device specific options (requires for most BSPs)
  • Also allows us to use the same mkspec to support multiple distros (hardfp/softfp)
• Currently supported boards/devices
  • ST7540, ST7108, Trident Shiner (PNX8473), Broadcom 97425, N9, beagleboard, snowball
  • More information here: http://qt-project.org/wiki/Category:Devices
• passing options to configure like -no-neon
  • https://codereview.qt-project.org/#change,27782

eglfs:

• No more depends on widgets, uses raster engine to paint widgets instead of opengl engine
• Integrated the build into configure
• hooks for board specific initialization
  • screen depth, format, gl caps
  • does not pollute board specific stuff into eglfs
• even has a xlib hook, so eglfs can be tested on the desktop just like wayland
• input
  • eglfs now depends on evdev. Future task is to make it compile when evdev is absent but we are yet to see such a device (qnx?)
  • can now be without udev, we have a static discovery
  • moved to platformsupport
  • eglfs loads input statically avoiding obscure args like -plugin EvdevKeyboard
  • synchronized position with multiple cursors
• minimalegl is the old eglfs
• cursor support
  • by default, you get a gl “composed” cursor
  • supports hotspots
  • hw accel on the pi, the cursor is a separate layer
  • it’s now CI (compile) tested
• allows creation of multiple windows and supports the surface format requested by the user
  • required for context menus
  • qmlscene —transparent allows one to create a transparent toplevel
  • on the pi, each window is a layer. poor man’s wayland
• Jorgen suggested moving large parts of code to platformsupport and move device stuff to separate repo
  • Will be investigated post 5.0

directfb:

• similar hooks design as eglfs
• integrated into configure
• supports IDirectFBGL and DirectFB+EGL
• holger maintains directfb these days

pkg-config changes:

• no more a second class citizen for embedded targets unlike qt4
• -force-pkg-config was used only for xcompile builds and used to just check for environment variables.
• Checks PKG_CONFIG_LIBDIR instead of PKG_CONFIG_PATH since the latter pulls in host paths. Checks PKG_CONFIG_SYSROOT_DIR
• (no)pkg-config works for all builds, default ‘auto’
• pkg-config env variables are now stored as part of qdevice.pri (“session”)

configure:

• -sysroot now being actively tested and it also documented
• Saves it’s output into config.summary
• Fixed QPA plugin detection
  • -qpa foo sets the default qpa
• Still have the problem of runtime of autodetection
  • Decided that this was unnecessary

What’s coming

• Hardware image decoding for the pi (based on openmax IL – girish)
• Layer based video rendering for the pi (based on openmax IL – johannes)
• qdoc documentation
• passing options to configure like -no-neon
  • https://codereview.qt-project.org/#change,27782
• Host tools when xcompiling
• Support for host compilation with -device
• Out of the box serial port configuration with QSerialPort

What’s missing from Qt4/Embedded support

• linuxfb needs to be resurrected
• openvg backend
• wayland will be suggested for multiprocess support, eglfs for single process

Qt Quick Components – Qt Contributor Summit 2012

Participants

Leonardo, Nokia – working on qt-components since the beginning focusing on meego/symbian; what would we like to do for Qt5 components wise? We have alot of xp and would like to share it
Jens, Nokia – main developer of the desktop components
Frederik, Nokia – accessibility in QML and qt-components
Shawn, Nokia
Florian, Tim, Loïc, Gerry, Ubuntu/Canonical – working on components for Ubuntu
Daker, INdT – working on theming for components and plasma components
Arvid, RIM – solving the components problem in a quite different way; session tomorrow on Cascades
Gabriel, Nokia – Meego components
Thiago Lacerda, INdT
Anselmo, INdT
Luis, INdT

Notes

• people seek continuation from qwidgets
• quality and completeness should meet what is in QWidget
• should we try to have common components at all? what can be common? APIs seem to be a common denominator
• we cannot contrain everybody to a single API that covers everything. we need to let people have additional platform/OS specific components
• should we have components exposed to C++? – RIM does it – to hide implementation details or for security – for official/recommended Qt5 we would like to only expose QML APIs – some things are not possible to do without C++ because of some APIs being private
• ‘simple’ components (buttons, tabs, etc.) are easy to have common APIs accross OSes and platforms; more complicated/custom components will be simply platform specific APIs
• need a tool to verify conformance/compliance of various implementations against common APIs
• desktop components solve 2 issues: – looking native – designing desktop oriented components APIs
• how do we do treeviews? lack of model
• the delegate approach to styling is interesting
• INdT’s target: desktop windows, mac, linux (KDE, GNOME)
• idea: creating a component set (2 maybe: a touch one and desktop) with a new/unique/not necessarily super polished that would serve as a reference for platform developers and a central point for API development; need for designers to design something at least basic; INdT could contribute designer time
• styling approaches? – delegate approach: every widget has a fixed API and logic but then the rendering is done via custom QML delegates; shortcomings: ? – INdT’s approach: description? – desktop components: description? reusing QStyle? supporting QStyle is painful; writing QStyles properly is difficult
• RIM does not have a styling problem: they just implement their own thing
• QML is a style language; no need for CSS? people think it would be nice to have CSS support because people know it; it can be a later addition
• what would the development process look like? – qt quick desktop components: more ad hoc based on Qt – qt quick components: – using a tool for API conformance testing – API review sessions negotiating between platform stakeholders (symbian, meego)
• minimalistic API in philosophy (QML is easy to extend)
• multi selection list views would be useful

Actions

Main action for all:
Implement a reference set of touch and desktop components that have their unique styling and serve as a single point of reference and home for common API development

• Schedule styling discussion [DONE]
• check copyright and licensing of components: BSD, for meego and desktop components copyright is Nokia [DONE]
• Write summary of styling discussion & approach proposal with examples inspired from INdT’s approach and qt quick desktop components’ approach + reach out to Plasma people; Jens showed a wonderful experiment based on the desktop components that demonstrates the approach beautifully [DONE]
• Try to make API conformance checking tool public [LEONARDO]
• Create qt-components mailing on Qt project: http://lists.qt-project.org/mailman/listinfo/qt-components [DONE]
• decide on a place to host the reference set of components; one repository with all the components (touch and desktop) and a smart directory structure [ALL]
• refresh wiki page http://qt-project.org/wiki/Qt_Quick_Components and see if and how to merge with http://qt-project.org/wiki/QtDesktopComponents → http://sketchpad.cc/B8MntLJEzp current state (unformatted) [GERRY & DAKER – IN PROGRESS]
• Check if some designer time would be available for designing very very basic visuals for reference component set [INdT]
• List common components that would be good to develop; maybe use the cross section of the most popular toolkits [GERRY, TIM, FLORIAN, IN PROGRESS BELOW]
• Define and document publically API development process [DONE]
• Create a table showing the correspondence between QWidgets and QML components – we will not replicate every single QWidget. [?]

List of common components

Platforms looked at:
touch: jQuery Mobile, Cascades, Meego components, iOS (UIKit), Android
desktop: Qt Desktop components, Plasma
https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Ajl6r4psredKdERGSUl1WGR1WVBhTWlSUXVsbXEtWkE
Please request write permissions if you like.

desktop and touch

Button: jquerym, cascades, qt desktop, Meego, iOS, Plasma, Android
Label: iOS, Meego, Plasma, cascades, jquerym (via html), qt desktop, Android
Toolbar: iOS (UINavigationBar), Meego, jquerym, Plasma, cascades, qt desktop, Android (ActionBar)
TabBar: iOS, Meego, Plasma, cascades (TabbedPane), Android (TabHost), qt desktop, jquerym (navbar)
Checkbox/Switch: Meego, Plasma, Android, Cascades, qt desktop, jquerym (via html), iOS
RadioButton: Meego, iOS (classname?), Plasma, Android, jquerym, qt desktop, cascades (RadioGroup)
TextInput: qt desktop, jquerym, Plasma, Android, Meego, iOS, Cascades (TextField)
Slider: qt desktop, Cascades, jquerym, Meego, Plasma, iOS, Android
ProgressBar: qt desktop, Cascades (ProgressIndicator), Meego, Plasma, iOS, Android
ScrollBar/ScrollArea: qt desktop, Plasma, iOS (ScrollView), Meego (QML Flickable, no scrollbar), Android
Split buttons: Meego (ButtonRow/ButtonColumn), jquerym, Cascades (SegmentedControl?)
Dialog: Meego, Plasma, Android, iOS (popover/AlertView), qt desktop, jquerym
ComboBox: qt desktop, jquerym (select menu), Cascades (DropDown), Android (NumberPicker)
List/ListItems/ListHeaders/Dividers [various types, requires deeper investigation]
Grid/GridItems
Layouts/Row/Columns
SpinBox: qt desktop, Android
ContextualMenu: qt desktop, Plasma, Android
Systray/Indicators
Date/TimePicker: jquerym, Cascades, Android, iOS

desktop specific

TableView: qt desktop, Android
TextArea: qt desktop, jquerym, Plasma, iOS
Frame: qt desktop, Android
MenuBar: qt desktop,
TreeView:

touch specific

PageStack: Meego, jquerym, Plasma, iOS
Spinner: Cascades (ActivityIndicator), Meego, Android, Plasma (BusyIndicator), iOS

API Development Process Ideas

• process to happen on mailing list
• 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

Taken from http://sketchpad.cc/XKp1Bs7LEp

• Thursday: Demo of a QtQuick 1.1 based (4.8) business desktop application (Nils)
• Thursday & Friday: Demo of how easy it is to hack wiimote support into Qt5/qtsensors. (DenLadeSide) – source for hack: https://gist.github.com/2996571 , source for WebApps demos: https://github.com/larsgk/webdemos
• Friday: Demo of Playbook Qt5/Qt4 apps and showing QtCreator integration(aholza , “Till Adam”) – http://blackberry-community.github.com/Community/Qt.html
• Friday: Demo of Quasi-Engine, a toolset containing ready-to-use QML elements for entities used by most of 2D games (tnoleto, “Tomaz Noleto”) – https://github.com/INdT/Quasi-Engine
• Friday: Demo of Snowshoe Desktop and Mobile, a Qt5 WebKit2 Browser. (jeez, “Jesus Sanchez-Palencia” and “Marcelo Lira”) – http://snowshoe.cc
• Saturday: “The Incredible Circus” Level Editor (QtQuick 1.1) . (“Renato Chencarek” and anselmolsm, “Anselmo L. S. Melo”)

Program

WORK IN PROGRESS

We are only pre-scheduling a few slots: plenary sessions, Qt Essentials modules,

• Galerie is the main room, with capacity for all participants.
• Seminarraum IV hosts about 100 people.
• Seminarraum I, II, III host each about 30 people.

Thursday, June 21

Friday, June 22

Saturday, June 23

Plenary sessions

Sessions that will not overlap with each other and that will be videotaped. On each day, we will close the plenary sessions with a hack ‘n’ tell.

• June 21: State of the union – Qt 5 and Qt 5.1: Opening session summarizing where we are and where do we want to go.
• June 22: Betting on Qt Quick: Theming, platform integration, cross-platform … We want to invite the maintainers and a few vendors/users/contributors to expose their thoughts and needs with the hope of bringing a common understanding.
• June 23: HTML5 & the web: A pannel including Qt WebKit maintainers and other users/contributors driving this area.

Demo sessions

Each day will end with a demo session. We want presenters to show cool hacks that make use of Qt in some way. No slides allowed. 5-7min per presenter. To keep switch-over time short, demos must run on session’s laptop. To show demos on special hardware, we will use a table-mounted video camera. We roughly want the demos to match with the day’s other plenary sessions.

Scheduled sessions

Qt Essentials: Maintainers present current state, past work over the last 6-12 months and give outlook for Qt 5.1. Session attendees should discuss urgent bugs that need fixing or bring up new feature requests.

Selected Qt add-ons that will be scheduled, because we assume they would have been proposed as ad-hoc sessions anyway.

Speaker / Session host information

If you prepare slides or want to attach your laptop, note that all projectors require the following resolution:

• XGA, 1024×768 (4:3 ratio)

Even though it might, do not expect any other resolution to work!

Qt Night Fever

Social Event will take place Friday Night.

Notes of QWidget session, June 22, 2012

General

• Great interest in QtWidgets
• Code base actively ported to Qt 5, far from dead.
• Present company considering maintainership

Candidates for new widgets

• Breadcrumb navigation
• Progress spinner
• Make use of KDE Frameworks 5
  • Clear button in QLineEdit
  • URL button, etc.
• Check out widget galleries from other toolkits
• Be aware of platform-specific IP protection

Help with migration from Qt 3/4 to 5

• Desktop QML components (using QStyle)
• Wrap QWidgets in QML container element
• Educate developers about UI/backend separation
• Converter of .ui files to QML?

Open Issues

• Regressions in QGraphicsView
• Fixes needed for Mac OS X Lion
• Investigate Windows 8 Metro
• Get message out about QWidgets being alive

Why?

Board having HW-accelerated OpenVG: RasperryPi, freescale iMX6, other (lower level) freescale boards. Some of these boards have separate hardware for VG and GLES, meaning using VG where it makes sense could take better advantage of the hardware’s capabilities. This is the case for FreeScale boards, but on BCM2835 (Raspberry Pi) OpenVG and GLES share hardware resources.

Possible fields of improvements/enablers

• basic enables like: QSurfaceType, QWindow, (for the future within a possible: QOffscreenSurface)
• qtcompositor using native-openvg
  • implement a minimalistic set of qml/declarative components + a corresponding, kind of openvg-scenegraph.
  • in the first iteration of the components-sets could be limited to wayland-window + animations
  • later some additional openvg primitives and effects could added
• maybe enums in QtGui

resurrect openvg paintengine:

• quick1/webkit1/widgets
• as a separate module
• caution: we need to set openvg flags when creating eglcontext … QPA-level
• openvg-widget as viewport

Webkit2

• There is already enablers in WebCore:: GraphicsContextOpenVG.cpp
• Anyway a lot(!) of work for qt-webkit2 because it’s mainly QImage based and makes a lot of assumptions on being on raster/CPU-memory
• A first, “small”, isolated task could be html5-canavas painting in qt-webkit2

Quick2

• canavas in quick2
• same code as webkit2-canvas?

Discussion Topics

We want want to be even more attractive and inviting come Qt 5.x with our newly improved documentation. Session will discuss upcoming work and issue to get to the goals set for 5.0 Beta, and if time permits, beyond. As the reorganization and change docs are undergoing need to effect everybody to achieve better documentation quality, ideally, wide maintainer participation is desired. However, perhaps for practical reasons, a rep. maintainer per each module or set of modules defined as functionality ‘X’ in attendance suffices. This maintainer will then commit to communicate to his team notes and practices pertaining to docs.

I hope this session will split to hacking sessions to do actual work on issues that could require guidance to boot strap (QDoc fixes, improvements, module docs restructuring etc.)

Technical issues

Making Documentation Modular

• Current status?
• Issues: Build dependency chain, intrusive changes, cross reference lost, Inherited by” broken ?
• Expected % done by 5.0 ?
• Improvements for beyond 5.0
• How maintainers can help? developers? interested documentation contributors?
• Modularization example / study case?

Documentation Build System

• How to KISS beyond modularization?
• Need to properly document build system for sake of next generations and outside contributors to hack; improve and extend.
• Current build system docs: improvements, dummy tests?

QDoc

• Errors in docs due to lack of knowledge of QDoc syntax.
• Missing QDoc syntax compared to Doxygen?
• Replacing of “old” QDoc syntax.
• Manual needs review, bug reporting , triage and fixing – http://doc-snapshot.qt-project.org/qdoc/
• How to engage community (users, maintainers) to help?

Format and Layout

• Modules follow different documentation styles.
• Example structure – description of example comes first now, other improvements for usability? (we should do some hands on review in a hack session).
• Examples need rewrite away from QWidget.
• Implementation hints in Qt Documentation?

“Social” issues (Content and infra.)

• Documentation bugs assignment in JIRA? (‘team’ mailing list, unassigned, community?)
• Doc bug maintenance https://bugreports.qt-project.org/secure/Dashboard.jspa?selectPageId=11521 ; triage and ownership – who takes care? (user community, developers, maintainers ?)
• Doc team spanning Nokia and community contributors:
  • How to gather new doc contributors?
  • How to engage maintainers , users ?
  • Establish a process for documentation review.
  • Consolidating recurring questions into recipes ? (example, http://lists.qt-project.org/pipermail/interest/2012-May/002146.html )
• Center of contribution howtos; Wiki content for people interested in contributing to documentation?(Intro ,How to checkout docs, build, change, merge request etc.)
• Establish a place where to read about all changes in doc practices and markup changes, for example to make sure things like http://www.mail-archive.com/development@qt-project.org/msg02347.html and http://www.mail-archive.com/development@qt-project.org/msg02443.html are easily found if someone expects some functionality and see different results.

Misc

• A plugin [chrome.google.com] for Google Chrome web browser supporting search for class names in the address bar. Discuss bugs/suggestions etc. in the forum, please

Qt Pim session

Session host: Cristiano di Flora

Session preliminary topics.

Please add here any topics you would like to discuss together at CS 2012 about Contacts, Organizer, or Versit API as well as ideas for brand new APIs to be added to extend Qt’s Personal Information Management API portfolio.

• Main functionality of each API (QtContacts [doc-snapshot.qt-project.org], QtOrganizer [doc-snapshot.qt-project.org], QtVersit [doc-snapshot.qt-project.org])
• Key differences between old QtMobility APIs and Qt 5.0 PIM APIs
• QtPim APIs beyond 5.0 (extensions to existing APIs, new APIs)

Agenda and notes from the session

Key differences between old QtMobility APIs and Qt 5.0 PIM APIs

Details / Fields system

• From String-based representation to Enum values
• No mutable schemas anymore
• Added ExtendedDetail detail class as simpler mechanism for clients to store custom details

ContactId

• From String based to dedicated Class (to be specialized by engine implementors….same as in Organizer)

QContactRelationship

• From ID-based to QContact-based interface

QML APIs

• Removed “dynamic properties” mechanism
• New Features added to model API
• Performance improvements to Contact model implementation

Future Work

Organizer

• TimeZones support(!): Coming to QtBase on 5.1. Everybody contributing to Organizer need to follow it up and there is room there for contribution from Organizer contributors as well

Contacts

• Improve support for social networks / social data
• Aggregated contacts / concept of “Persona”

Common (C++ APIs)

• Observer / Watcher class separated from Manager (QContactManager, QOrganizerManager)

Common (QML APIs)

• Create more narrow-scoped models
• Remove Manager logic from model elements and create new “Manager” elements for each API
• Add support for batch save operations
• Improve memory consumption
• Error codes from String-based to Enum values
• improve documentation

Backends(!) needed

• OSX
• KDE pim: Kde pim is having support for handling the opposite use case (mapping QtPim data to kde-pim). For QtProject would be beneficial to do this the other way around (having kdepim- QtContacts and QtOrganizer backend plugins). This should be discussed and designed / agreed via mailing list + gerrit + irc.