Tag: qt

Concerns about Qt’s increasing commercial focus

Road closed sign

It’s not just me. Phoronix is reporting on growing concerns in the Qt community about the project’s increasing commercial focus and apparent deprecation of its open source core.

I have said many times in these pages and elsewhere that I really like Qt: it’s the right tool for a lot of jobs. But increasingly I’ve been feeling that any contribution I make in educating users about Qt is benefiting a commercial enterprise and not a community tool. So much so that I am re-surveying other open source multi-platform libraries to use as an alternative to Qt.

If the community no longer has meaningful Qt ownership, a lot of users will no longer be interested.

On the hidden dangers of highly integrated application frameworks

qupzilla-failure

I have been evaluating WebKit and Blink-based open-source browsers for Linux—mostly because Firefox is often noticeably laggy on an old laptop I like to use. (I still <3 you though, Moz!!) Chromium is an obvious option, but I would like to investigate solutions that don’t rely on Google. This has led me to Midori and QupZilla. Both position themselves as lightweight alternatives to the big kids. Both have their pros and cons.

A con with QupZilla that I want to take on in this post is the result of its use of Qt. I love Qt. It’s the right tool for a lot of jobs. But it harbors a hidden gotcha when it comes to rendering web pages: you are at the mercy of the Qt maintainers’ web rendering engine update policies. The latest version of QupZilla that you can build with the production version of Qt (5.5) uses QtWebEngine, which is based on the Blink-based Chromium. (So much for not relying on Google!)

The current Qt release bases QtWebEngine on Chromium 40—which is almost a year old; the next Qt release (5.6) will base QtWebEngine on Chromium 45—already three months old. The version of QupZilla provided by Debian sid (unstable, rolling release) uses the deprecated QtWebKit, which in Qt (5.5) is based on Webit 538.1.0. This version of WebKit is already a couple years old.

A similar situation exists with Midori. It uses GTK’s WebKitGTK+, which in Debian sid is as of this writing at 2.4.9-2 and also is about about two years old. Probing the user agent indicates it uses WebKit 538.1.5. But as there is in Qt, there is an additional wrinkle in the GTK+ world. There are currently two versions of WebKit for GTK: WebKitGTK+ and WebKit2GTK+ . Depending on which one your GTK+ application uses, you may get an old or a new version of WebKit. The version of WebKit2GTK+ that ships with Debian sid appears to provide WebKit 602.1 at the moment, which is the current point-release WebKit, and new releases of WebKitGTK+ flow regularly.  (Why Midori doesn’t use WebKit2GTK+ is a question for the developers and one that I hope to pursue. FYI, GNOME’s Web, née Epiphany, uses WebKit2GTK+.)

Whatever the specifics may be in this case, the takeaway is this:

When using integrated application frameworks, you need to be aware of versioning limitations with third-party tools that they bundle.

Android VM Manager

I just released a tiny Qt widgets-based app that makes it more convenient to connect an Android virtual machine to your development environment. Here’s a quick (but possibly not quick enough) demo of configuring it to work with AndroVM and the Eclipse-based ADT Bundle:

I’ve successfully used it with Android-x86 as well. I gotta say that doing development with either of these VMs is much faster and more rewarding than using the emulator that ships with the ADT.

The code is available on my Bitbucket at https://bitbucket.org/mithat/androidvmgr and is licensed under the GPLv3.