Thurs 12.01.11 – Today was the third and final day of Qt Developer Days in San Francisco (Airport area), being the last day it was a bit more relaxed and the sessions where more give and take. I have really enjoyed this conference, not only for all of the new information learned but for the high caliber of people I have met. I will definitely go again next year.
I have one more post of the photos from the event to come but the photo essay will need to wait until the weekend.
My notes are mostly a transcription but sometimes a paraphrase of what the speaker said and what their slides said, if exact quote then I will put it in “”. The use of () is my notes or asides or thoughts.
Qt Dev Days 2011
Thurs Dec 1, 2011
Choose your UI WEapon QML, HTML5, C++
No technologies are going to die, it is all about who uses them.
Trying to compare a spec, a programming language and a framework.
HTML5 is a spec, C++ a languange, and QML is a framework.
I will be comparing QML to a HTML5 framework or QWidgets, to level the playing field.
Use toolkits, don’t let toolkits use you.
Portability – how well can I reach all my customers with my software?
Productivity – how quick it is to get from an idea to production? To modify? How many devs to change a light bulb?
Performance – how well is it running?
Think about your use case and how dynamic it the following:
UI – QML
Content – HTML
Visualization/Data – C++
Dynamic means how the user can interact with the UI, content, data
C++ Widgets – very scalable, works esp in desktop
QML Components – very productive, best for mobile & embedded
C++ – QGraphicsView + QStateMachine – robust but verbose
QML – declarative property binding and QML application support, built for animations in mind – best for declarative animations
CSS3 – also declarative, CSS originally built to format content, animation was added later on – declarative and portable
C++ – QPainter, very robust
HTML5 Canvas – original spec from Google looked to C++ for inspiration, 80% of what you need with 20% of the complexity
QML Canvas – is a copy of HTML5 Canvas, nice thing is that one can use C++ with QML
HTML5 – visualization is done in concert with data from the network
Rock solid tools vs zero-install on modern browsers
Layout – this is a difficult issue
C++ – Qt Widget Layouts, good for consistent desktop layouts cross-platform
QML – Anchor layout for animation, important for mobile and touch
CSS – Flexible box, HTML is about layout in content.
“I don’t like the notion of desktop, what is a tablet?”
C++ – Don’t need bindings
QML – strong native bindings
HTML5 – Qt WebKit Bridge, less powerful but does the job
C++ & QML: Platform Security
HTML5: browser sandbox
1st class: Desktop, N9, Symbian
Also: Android, iOS, RIM
1st class: iOS, browsers, RIM, N9, hybrid apps
Also: Android, Symbian, WP
Fast v Deep v Broad
Fast – QML: Quick to develop, extend, render
Would use QML for Mobile apps, Quick iterations in GUI
Deep – C++: As integrated as possible
For desktop UI, deep integration with the underlying platform, complex visualization
Broad – HTML5
Serve from anywhere, deploy from everywhere. For cross-platform mobile & tablet apps, browser deployed solutions, content heavy applications
QML don’t be slow
HTML5 don’t be narrow
C++ don’t be shallow
Using Qt Quick for Rapid UI Prototyping and Development
Jens goes right into Inkscape and Qt Quick to show us how he will develop his app
Jens creates a prototype of Flickr photo viewer
How to integrate Multimedia into Qt
in Mobility, but works for desktop & embedded
Future of multimedia in Qt5
MM will be a part of the Qt essentials core, so it will always be there
Qt Multimediakit plays well with Qt Quick
Qt Quick elements
Beyond the Basics
Create your own QML elements
Use advanced capabilities in …
Jonas gives a demo on how to create a video player in QML
For his tone generator demo he is using Qt & C++
Then he creates a QML beat box
How to do Qt Contributions [Qt Project]
Marius Storm Olsen & Thiago Maciera with many comments from Lars Knoll
(Jen missed the first 12 mins of preso due to talking outside)
Peer reviewing is enforced
Automatic checking by Qt’s continuous integration (CI) system
Submitting to Qt Project
* Subjective Questions:
– Is this contribution talking Qt in the right way?
* Objective questions:
Is the code properly doc, tested, styled, and reviewed?
Has it passed all regression tests?
Does it introduce risks, complexity or performance penalties?
There’s more to life than code
* Other activities:
Keeping wiki pages up to date
Helping newcomers out with the setup
Improving test coverage
Bug triaging, QA
Roles and responsibilities
for contributors, approvers, maintainers, chief maintainer
Approvers are the cornerstone
* Approvers are contributors who can approve contributions
* Decisions guided by Spirit and Technical fit – to be peer reviewed, approvers shouldn’t approve themseleves
Maintainers are normal people
* Maintainers are the people responsible for a particular module, port or component
They must know what’s going on
They must ensure every contribution is reviewed
They get the privilege of setting direction
* Only one for the entire Qt Project
Primo inter pares among the maintainers
Final decider in case of no consensus
Progressing in responsibilities
Approver: you need the support of two existing approvers, you need to have proven your dedication to the project
Maintainer: only if there’s code in need of a maintainer, you should already be acting as a maintainer
* Ensures the quality of the codebase
maintains the systems used for checking
produces reports on coverage, failure rate, etc.
* All Tier 1 platforms need to do the same
* Responsible for getting the packages out of the door
Platforms must participate in the release process to get “Tier level” support
* Release is both time and quality driven
Process starts strictly on time
Package release on quality criteria
* Meritocratic decisions, on technical grounds
Consensus should be reached if possible
Escalation to maintainers or the chief maintainer if consensus is not reached
* All decisions public:
Discussion on the mailing list(s)
Documented in the wiki, if necessary
Small digression due to a question:
Qt channel is for Qt users
Qt Labs channel is for folks developing Qt
IRC discussions are non-binding until they are posted to the mailing list, and discussed there.
The mailing list is the only thing that works for everybody.
* Other communication channels:
IRC channels (#qt-labs on Freenode)
Face to face meetings
The Qt Contributors’ Summit
And other events, like the Contributors’ Day
How to contribute?
Up until now (the past): Processes differed if you were a Nokia employee or not, non-employees had to use Gitorious’ Merge Request system
Causes the problems: Nokia engineers had to context switch from their normal day to day workflow, legal scan of any non-trivial contribution had to be performed, then the Nokia engineer became responsible for ensuring QA, and then reaching the right people was difficult.
Solutions to the past problems:
* Same workflow for everyone – the workflow we always wanted to have – peer review, agile, etc.
* Powerful code review tool
* Mailing lists with all relevant developers
* No Nokia legal scans in the Qt Project
* No transfer of responsibility
* QA results available to all
[diagram with flows of acceptance or rejection, not going to reproduce in text]
How it is going to work from now to the future
* Some things stay the same:
We use Git
Someone other than the author must review using the web interface
* Some things change:
Submission of contribution done from the command line, using git push
Live demo of how to contribute:
Q? How to know what is being worked on so that there is not duplication:
Jira – set up a task, IRC, and ask someone on the mailing list
if you want to know who owns some code & are the maintainers, then look on the wiki