Having announced qmlbook.org yesterday, the reception has been fantastic! Over two thousand unique visitors from all over the world (see the map below) and almost 8000 page views. Add to this that we clashed with the Qt 5.2 release announcement, and I’m overwhelmed.
Juergen Bocklage-Ryannel and myself are writing a book! As we’ve reached the point where we want to share our work with the workd, we are happy to open the doors to the book Qt 5 Cadaques – A Book about Qt 5! It all started a couple of years back, when two developers saw a need: there where no books approaching Qt from the QML side. We decided to solve the problem by writing a book.
During these years, lots has happened in the land of Qt. The ecosystem around the Qt Project has stabilized after the whole Microsoft-Nokia thing. Jolla has released a phone with Qt 5, as has Blackberry. Ubuntu Phone will be based on Qt 5. The Raspberry Pi has taken on the whole world with a great hardware that runs great with Qt 5. It is now possible to target both Android and iOS using Qt 5.
Looking at these changes, one can see that Qt really has grown towards mobile. Towards device user interfaces. User interfaces where the look and feel has to be integrated into the context of a physical device. This is where Qt Quick and QML really shines. Before I go on, it is worth pointing out that the Qt ecosystem has grown towards mobile, it has not moved there. The cross platform desktop support is still there and works just as great as it has for almost 20 years now!
For aspiring Qt developers, there is a plethora of documentation for using Qt from C++. There are multiple books on the topic. However, when targetting devices, C++ is only a part of the story. Here, Qt Quick and QML are equally important. That is why we are happy to make Qt 5 Cadaques available!
A final word of warning. The book is being written as you read it. We believe in the open source mantra release early, release often. This means that the text currently is in its early stages. We have setup a feedback system so that you as a reader can help us improve the material by pointing out issues. We are also looking for ways to grow the contents. We also keep a project blog on the site to announce our releases and to ask you about your opinion on the book. We would love for you to tell us what you want to read about!
A couple of nights ago, Daniel Stenberg visited the Pelagicore offices in Gothenburg for the Raspberry Pi Night. We had 28 signed up guests and hacked, talked and played for a night.
I was personally surprised about the turn-up – and the number of projects showing up. A couple of guys even came with a lab power supply and their own embedded computer running a SNES emulator. Cool stuff! Some figures around this. We filled the event (28 tickets) in 4-5 days. We got 40+ people on the foss-gbg mailing list in two weeks.
I’d like to thank everyone who showed up. Great to see a large crowd! I’d also like to thank Daniel for coming, Pelagicore for hosting and supplying food, a location and competition prizes, and to all my colleagues who helped me in the preparations. As this really took of, I’m already planning for our next event. If you want to brain storm about topics, feel free to drop me a mail (e8johan, gmail). I’m already thinking 3D printing, quad copters, node.js in embedded, Wayland, etc.
Looking past the irony that QML will be available for all platforms but WP8 in the short-term, and Nokias previous involvement in the development of QML, it is nice to see the platforms being created.
The last in the row is Ubuntu Phone, others are Jolla’s Sailfish, RIM’s BB10 Cascades, KDE’s Plasma and Nokia’s Components for Harmattan and Symbian. Qt seem to unlock the future UIs for devices.
What is striking is the interaction patterns being established. Nokia Swipe, Sailfish as well as Ubuntu Phone seems to rely heavily on swiping from the sides of the screen. This is, in my experience, the key to a truly one-handed device.
Using Android, you are constantly forced to hold the device in awkward angles or use two hands to reach the home button, be it physical or on-screen. Swiping with the thumb is always possible when using one hand (as long as you have an opposable thumbs), while the two-handed user can swipe using the index finger without feeling hindered by the interface.
From a development perspective, it is interesting to see how the different QML Components are shaped. Ubuntu seems to have some interesting ideas for theming going on, and the other platforms have their own strong points.
One interesting comparison is to look at the API for a single component. Comparing the CheckBox elements of Ubuntu Phone, BB10, Harmattan, Symbian and Plasma gives the following API (only looking at the properties and signals that I regard as relevant to the comparison in question).
Properties
Signals
Where does this leave us? For all platforms, one can use the checked property and its onCheckedChanged signal to act. The rest is in up in the air. Ubuntu Phone seems to split the text from the checkbox while the others keep them together. The enabled property is missing from most platforms. Here, even Symbian and Harmattan, both from Nokia, seems to differ.
Still, as the concepts seems similar, the work to create a cross-platform set of components wrapping the components of each platform should not be an impossible task (looking at checkboxes only, that is). Hopefully the end result will not be a too fragmented API landscape and the involved parties will work towards a common setup of basic properties and signals.
Either way, I’m happy seeing that 2012 was a bad year, 2013 looks very exciting. Seeing all these innovative phone user interfaces being created with QtQuick, I’m happy to work at a company innovating in the automotive space using the same technology.
Disclamer! These findings are based on the API docs only. Feel free to correct me by commenting.
So, I’ve taken the time to shift my development target at work to Qt 5 beta 2 (from beta 1). Most things work perfectly, however, qmake has changed its behaviour slightly – in a subtle evil way.
First, some background. I’m building a QML plugin. When building it with beta 2, it no longer loads as it could no longer resolve the vtable for one of my classes.
$ readelf -sW /home/e8johan/work/prf/lamprey/lamprey/lib/liblampreyqml.so | grep UND | grep QmlAudioHardware | c++filt
45: 00000000 0 NOTYPE GLOBAL DEFAULT UND vtable for QmlAudioHardware
47: 00000000 0 NOTYPE GLOBAL DEFAULT UND QmlAudioHardware::nameChanged()
50: 00000000 0 NOTYPE GLOBAL DEFAULT UND QmlAudioHardware::volumeChanged()
288: 00000000 0 NOTYPE GLOBAL DEFAULT UND vtable for QmlAudioHardware
301: 00000000 0 NOTYPE GLOBAL DEFAULT UND QmlAudioHardware::nameChanged()
308: 00000000 0 NOTYPE GLOBAL DEFAULT UND QmlAudioHardware::volumeChanged()
What was this all about? I looked at the source, commit logs, everything – nothing had changed and everything was in place. Inheritance – check, Q_OBJECT macro – check, file listed in HEADERS in the pro-file – check…
Then I started to look at what was actually built. Apparently not the moc…
$ find | grep moc | grep qml ./qml-plugin/build/moc ./qml-plugin/build/moc/moc_qml-plugin.cpp ./qml-plugin/build/obj/moc_qml-plugin.o ./qml-bindings/src/build/moc ./qml-bindings/src/build/moc/moc_http_downloader.cpp ./qml-bindings/src/build/obj/moc_http_downloader.o
Since the software I build worked, I simply built it using qmake && make -j5 and then went for a coffee. When doing qmake -recursive I notices a long list of header files that weren’t found:
$ qmake-qt5 -recursive ... Reading /home/e8johan/work/prf/lamprey/lamprey/qml-bindings/qml-bindings.pro Reading /home/e8johan/work/prf/lamprey/lamprey/qml-bindings/src/src.pro WARNING: Failure to find: qml_audiohw.h ...
Why?! Apparently, a colleague of mine has already reported a bug, and this is the way that it is supposed to be. I’m not sure that I agree. This totally breaks the point of DEPENDPATH to me.
The fix is easy, so now it works, but I’m not happy with loads of ../include in my pro-files due to the way my codebase is structured. I just wonder if this is what we really want…
Update! and it turns out that, yes, that is really what we do want. Apparently this feature has broken code (VPATH causing the wrong files to be picked up). So this is by design.
Update again! running qmake -Wall -r treats the missing header warning as an error. Highly recommended!
I’ve finally been able to find a time slot to try to summarize the Qt Developer Conference. This year I ended up spending lots of time in our booth, so I’ve visited surprisingly few talks. I’m really hoping that KDAB will be able to sort out the issues that they’ve had with audio, so that they can get them on-line. In the mean time, I’d like to share my reflections of the event. From my own viewpoint, is was great seeing so many familiar faces again. Seeing that the event sold out, i.e. 500+ visitors, was great. I knew that the Qt community was strong, but this is great!
From what they keynotes contained and what people said, I also like the direction that the Qt project is taking. Back to the deploy everywhere is something that I’ve been looking for a long time. I even talked about it at FSCONS last year, even though my topic was Necessitas (which worked too well to do a good tech session on it; what is interesting in install, deploy, run…) Hearing that cross platform is key and that Digia supports bringing it to both iOS and Android during 2013 is great.
Another nice thing is Jolla (not actually on QtDC) and BB10. It is ironic to see that what Nokia saw as a burning platforms is picked as the way forward by two competitors. Let’s hope that they succeed and can show app developers what Qt and QtQuick really can do.
Also, seeing the whole group of service providers working around and inside the Qt project makes me happy. Not only the big ones providing general services around Qt, but also smaller niche players. All are able to live because the productivity boost that Qt gives. Taking Qt to a niche of your own seems to be a great way to build a business.
Finally, I did my speech on the morning the last day. The room was deserted when I arrived, but everything worked. I was even able to convince my laptop to play nice with the projector. I’m happy to say that when I finally got going, it was full. There where even a few people standing along the wall. Thank you all for attending! The slides are on the conference page, but also downloadable from here.
Thanks for everyone making it possible for all the Qt developers to meet in 2012! Let’s all meet again in 2013!
I’m in the middle, or rather, approaching the end of, my very first large QtQuick-based project. I cannot tell you that much, just that it includes a rather large code base of QML, and a semi-large run-time environment written in C++. In this blog entry, and probably some more, I’ll tell you about my experiences.
The productivity of QtQuick feels amazing when doing small user interfaces. Especially when just putting something cool together to demonstrate the states and transitions abilities of QtQuick. However, as the deadline approaches I’ve learned that QtQuick development is quick only when compared to writing a Qt/C++ user interface consisting of 100% custom widgets.
Working with a design company, I had to identify potential components, write and test those components and then deploy them through-out the user interface. Simply importing full screens from Photoshop and blowing life into them just leads to code duplication.
The end results looks amazing. All that I’m saying is that having graphics on the screen in 15 minutes does not mean that you will be ready to leave by lunch.
Transitions in QtQuick is just amazing, but when designers start saying things like “scrub the timeline”, “initial movement to give a sense of direction”, et cetera, I hear “add complexity to your puny state-machine”. Currently, QtQuick lacks support for easily defining a transition over a complex path. The provided easing types do a lot – I, as a developer, thing that they look great, but being able to add key-frames to get that extra punch into the animations without having to use multiple states would be great.
One cool thing that I did learn in this process is that implementing a frame-by-frame animation from a set of PNGs is actually quite easy. Simply add a parallel animation group with the rest of your animations and linearly iterate the “currentFrame” property, and use said property in the source property of your image element. Felt like an ugly hack, but worked great!
QML really needs lint. My current deadline is due to smack me over the head real soon, so I have not got the time to looking into what can be done. However, double-checking names of states, ensuring that image files exist, looking for name-space issues (will talk about this later), et ceterea would be really helpful.
As Qt is open source, I guess it is easy to access a tree representing the parsed source. From there, it is simply a matter of applying rules. But, I have not looked in to this at all, so it might be much harder than I imagine.
I’ve run Kubuntu on an old MacBook Pro (revision 5.1) for over a year now, and it has worked great. However, last week, it became more or less unusable. It seems that some sort of blending operation results in noise.
When using the machine with some composition effects, it was completely unusable – moving a window resulted in a square or static noise. All edges of plasma widgets where covered in noise, etc. Disabling all effects meant that I can use the machine again, however, some noise prevails.
As you can see from the screenshot at the top of this post, it is visible in the panel. It is also visible in elements such as the slider and the upper right corner of the desktop folder plasma widget. Another factor is that the noise sometimes disappear when a repaint is forced, but it is “physical” enough to get caught in a screenshot.
So, dear lazy web, do you recognize this from somewhere? Is it the drivers? Is it something in kwinrc? Or is it hardware (perhaps graphics memory) failing?
Update. Thiago from Tro^H^H^HNokia Qt Development Frameworks^W^W^W^WIntel (apparently at a new job) told me to clear the image caches. Read the comment, follow the instructions, and everything works again!
>Ok, it has been days since the second alpha of KDE 4 was released so I’m late. Still, I’ve put together a small collection of screens where I’ve tried some of the new stuff in KDE 4. The alpha is really limited still, so hopefully the review of the next edition will be more interesting. In the mean time – check out the current state here: KDE 4 Alpha 2 test run.