Planet maemo: category "feed:a93f39245539231538463d349e184dd2"

When software goes slow, generally, the first reaction is to profile. This might be done through system tools (like Instruments on OS X, perf/valgrind/etc on Linux, VTune, etc). This is fine and good, but just because you have the output of a tool does not necessarily correlate to understanding what is going on.

I've had a long, quiet time on this blog over the past few years while I've been frantically helping Jolla to launch their self-named product: the Jolla. I've enjoyed (almost) every day I've been there: they really are a great bunch of people and the work has been plentiful and challenging.

But as the saying goes, "this too shall pass". Nothing lasts forever, and it's time for a change: after this week, I will be taking a break from Jolla to get some fresh perspective.

QMake users: public service announcement. If you use CONFIG+=ordered, please stop right now. If you don't, I'll hunt you down. I promise to god I will.

There is simply no reason to use this, ever. There's two reasons this might be in your project file:

you have no idea what you are doing, and you copied it from somewhere else

you have a target that needs to be built after another target, and you don't know any better

If you fit into category 1, then I hope you're turning red right now, because by using CONFIG+=ordered, you're effectively screwing over multicore builds of your code. See a very nice case of this here.If you fit into category 2, then you're doing it wrong. You should specify dependencies between your targets properly like this:

For those of you wondering why I sound frustrated about this, I've fixed so many instances of this by now that it's just getting old and tired, frankly. And I still keep running into more. That's countless minutes of wasted build time, all because of laziness boiling down to a single line. Please fix it.

Sometimes, for whatever reason, the layouts provided "out of the box" in QML just don't cut it. lately, I've been doing a few rather different things for experimentation and learning purposes that have meant I've run into quite a lot of these cases.

With 5.0 now being feature frozen, I thought I'd turn myself towards something I've been meaning to do (and talking about doing) for a very long time. Back before the Qt Project launched, even before Qt Contributors Summit 2011, in fact. I thought I'd make QFileSystemWatcher more useful.

Just thought I'd share some details on some of the recent changes I've pushed to Qt 5 a few weeks ago. (Yes, this post is rather overdue, I've been a bit slack with writing it). If you were in Tampere when I gave a short, completely underprepared Q&A on Qt 5 a few days ago, this won't be news to you, but I will go into a bit more detail.

tl;dr, all in all, a lot of code was deleted, and things still function more or less the same, except a bit better. That's quite a common story for Qt 5, I hope... :)

A few times, when I've been working on something performance-critical, I've had people suggest (or ask me to review code) using QRegExp. I usually tell them that "this is a bad idea, QRegExp is slow/unmaintained", but I never actually sat down to do benchmarks. Well, in Qt 5, the subject of replacing QRegExp has been discussed a bit, and we have a volunteer: Giuseppe D'Angelo, a Qt hacker and italian student living in the UK (looking for work, by the way!).

What's wrong with this? It's a very subtle problem. I'll give you a moment to think about it, and a video to see if you notice the problem. Make sure you don't cheat.(demonstrating removal of flicker in QML)Back already? Have you figured it out? That's right, it flickers. Horrifically.So what causes this? By default, QWidgets are drawn parent first, with parents drawing children. When a widget is drawn, first, it draws its background, then it draws the actual content. That background proves to be a problem, in this case.If we add the following lines to the above example, the flicker goes away, and my eyes no longer want to bleed: view.setAttribute(Qt::WA_OpaquePaintEvent); view.setAttribute(Qt::WA_NoSystemBackground); view.viewport()->setAttribute(Qt::WA_OpaquePaintEvent); view.viewport()->setAttribute(Qt::WA_NoSystemBackground);

NB: I'm not completely sure that adding it to both the view, and the viewport is completely necessary, but it can't harm at least. Make sure to re-set it if you change viewports.For completeness, here's the full, fixed example:int main(int argc, char **argv){ QApplication application(argc, argv); QDeclarativeView view; view.setSource(QUrl("qrc:/qml/main.qml")); view.setAttribute(Qt::WA_OpaquePaintEvent);

NB: on Harmattan (and Nemo Mobile) at least, make sure you always use QWidget::showFullScreen(). The compositor in use there unredirects fullscreen windows (meaning no compositor in the way), so you get faster drawing performance, and every frame counts.

For device manufacturers, and those targeting device manufacturers like us in the Mer¹ and Nemo Mobile².communities, we need a performant base, and Qt's default configuration on Linux is ..not really that performant. It uses what is known as the 'native' graphics system, which uses X (and XRender) to do a lot of the grunt work. Unfortunately, XRender isn't exactly what you'd call speedy in many cases, and making loads of round trips to ask X to draw things probably doesn't help either.

This isn't just a continuation of MeeGo, of course - nobody in the MeeGo community proper would argue that there is a need for change, and we've got a few lined up, such as an easier porting story to other devices and architectures (and a much friendlier community atmosphere to such projects), complete meritocracy, and many more.

To get one thing out in the open: this is just the core OS, a Linux distribution. There is no UI, and hardware adaptations are seperate from that core OS. It's an extremely slim Linux vehicle for making products out of. What you put on top is entirely your business - it's just a tool.

The idea being that you can then take it, drop a hardware reference for a device you love quite a bit, drop a UX in on top (either one you write yourself, or one from the greater community, like the MeeGo handset UX), and you have a product. Plasma Active is another example of what could be dropped in as a UX. The MeeGo handset community edition will most likely be looking to rebase on top of Mer in the near future.

In terms of the app stories available: Qt is available on Mer, so for developers seeking to target Qt, look to install Mer derivatives on your devices. This doesn't stop other toolkits or technologies, of course - all are welcome to come and base around Mer. We also have high hopes that we can achieve some base sharing with Tizen, and ideally, easily atain Tizen compliance. It is HTML5, after all.

I look forward to running a MeeGo handset UX on top of a Mer core on my n900 soon, and what can be accomplished in the future.

A lot of noise has been made about Intel closing up the MeeGo shop and heading for new waters, but predictably, a lot of people aren't very happy with this move, both individuals and companies who have products based around MeeGo.

I won't rehash the story any more than that, except to say this: MeeGo, or the ideals of it - an open mobile-oriented platform featuring Qt is still very much valid and needed, and it's not going away. There's some discussion already going on on the MeeGo lists about how best to continue, already.

Watch this space. MeeGo (in some form or other) is not dead, and neither is Qt.