Planet maemo: category "feed:a93f39245539231538463d349e184dd2"

Robin Burchell
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:
  1. you have no idea what you are doing, and you copied it from somewhere else
  2. 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:
TEMPLATE = subdirs
SUBDIRS = src plugins tests docs
plugins.depends = src
tests.depends = src plugins

And then you'll have docs built whenever the build tool feels like it, and the rest built when their dependencies are built.

If you have subdirectories involved in this, then you need an extra level of indirection in your project, but it's still not rocket science:

TEMPLATE = subdirs
src_lib.subdir = src/lib
src_lib.target = sub-src-lib

src_plugins.subdir = src/plugins
src_plugins.target = sub-plugins
src_plugins.depends = sub-src-lib

SUBDIRS = src_lib src_plugins

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.
Categories: C++
Robin Burchell

writing a layout in QML

2012-05-30 13:04 UTC  by  Robin Burchell
0
0
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.
Click to read 948 more words
Categories: coding
Robin Burchell

on the importance of doing nothing

2012-03-21 16:18 UTC  by  Robin Burchell
0
0
I've been meaning to write about this for a while, but I've only just now been driven over the edge by having to go and basically run sed over code again for no good reason.
Click to read 1030 more words
Categories: C
Robin Burchell

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.
Click to read 1346 more words
Categories: coding
Robin Burchell

QFileSystemWatcher internals in Qt 5

2012-01-22 11:42 UTC  by  Robin Burchell
0
0
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... :)
Click to read 1292 more words
Categories: C++
Robin Burchell
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!).
Click to read 858 more words
Categories: C++
Robin Burchell

Avoiding graphics flicker in Qt / QML

2011-11-23 20:02 UTC  by  Robin Burchell
0
0
It's very common when writing QML applications to write a small stub, something like the following:


int main(int argc, char **argv)
{
    QApplication application(argc, argv);
    QDeclarativeView view;
    view.setSource(QUrl("qrc:/qml/main.qml"));
    view.showFullScreen();
    return a.exec();
}

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);

    view.setAttribute(Qt::WA_NoSystemBackground);
    view.viewport()->setAttribute(Qt::WA_OpaquePaintEvent);
    view.viewport()->setAttribute(Qt::WA_NoSystemBackground);
    view.showFullScreen();
    return a.exec();
}

(If you're curious, Qt::WA_OpaquePaintEvent basically implies that you'll repaint everything as necessary yourself (which QML is well behaved with), and Qt::WA_NoSystemBackground tells Qt to nicely not paint the background.)

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.

(obligatory thanks to Daniel Stone of X and Collabora fame, for telling me to stop blaming X, and start blaming the crappy toolkits ☺)
Categories: C++
Robin Burchell

Fast UI with Qt 4 on mobile

2011-11-23 19:14 UTC  by  Robin Burchell
0
0
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.
Click to read 858 more words
Categories: graphics
Robin Burchell
A few days ago, I posted MeeGo not being dead until the fat lady sings. Now, the reason why I was being so cagey is out in the open: Mer is alive again, and aiming for MeeGo 2.0.

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.

If you'd like to talk with us, pop onto #mer on freenode or use the webchat. We also have threads on both the MeeGo and maemo.org forums, should you be a fan of those.
Categories: community
Robin Burchell

the beauty of open source...

2011-09-29 18:46 UTC  by  Robin Burchell
0
0
...is that it just doesn't die because somebody says so.

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.
Categories: community
Robin Burchell

on conferences, part #2

2011-07-01 16:35 UTC  by  Robin Burchell
0
0
Also late, but at least it's only a few weeks late, I also attended the first Qt Contributors summit, in Berlin in June. Berlin seemed like a fairly typical european city , at least to me, although my experience admittedly isn't that broad yet. I had a few problems with some unfriendly locals making my trip a little more hasslesome than it would perhaps have been otherwise, but all in all, I quite enjoyed it. I don't think my friend John did, though, as he lost his luggage. :)

Meeting so many Qt folks was great, the content of the discussions was intriguing, and I'm sure that some solid work has been laid for the future. I know that I got quite a few ideas for my current pet project, poking at the guts of QFileSystemWatcher to make it much more useful, and hopefully less resource intensive (in most situations) by means of not using a thread internally for no good reason. But that's material for another day.
Categories: berlin
Robin Burchell

on conferences

2011-07-01 16:29 UTC  by  Robin Burchell
0
0
Just a short post, as I'm by now fashionably late for this.

I attended MeeGo Conference in San Francisco in May, my greatest thanks to my excellent employer, Collabora Ltd for sponsoring my trip. It was a pretty intense week for a lot of reasons, one of which being that the week before my visit, I was asked to demonstrate some software I have been working on, a sort of mesh synchronised object store.

I showed off a simple contacts application synchronising contacts across three devices, but my real plans for that are a lot more - but that is content for another post, perhaps, another day. I think the show went pretty well, certainly, the reception of some parts of the keynote was a bit mixed.

It was also the first time I have visited the US before, and it was certainly a different experience to practically anywhere I have been before. San Francisco was an interesting place in particular to visit, with extreme contrast (people living on the streets with obvious mental issues, while there are villas in the background etc.) and typical cultural differences, some of which I found quite strange, like mandatory tipping. All in all, I think I'd visit again, though.

The conference itself was quite excellent, lots of interesting talks going on, and as usual, meeting all the familiar faces - and making new friends - was fantastic. I only wish I had been less frantically busy and jetlagged (or tired after being busy) to make more of the experiences. By the time I had recovered from everything, the conference was almost over. Though thankfully, I spent an extra two days wandering the streets of the city seeing some sights.
Categories: community