Tag Archives: Qt

Cute Contacts for iOS – video demo

Some time ago I have started Cute Contacts a project for studying how well QML as of Qt 5.3 is fit for prototyping iOS app. By now the project is done enough to see how fit things are. On the way I have found a few bugs, found some generic inconveniences and learned a lot.

I will probably post more on the findings, possibly it could help Qt project folks to save some time when developing Qt Quick controls for iOS. For now, just have a look at the video. For more details watch the project page or subscribe to this blog RSS feed.

And sure feel free to grab the code on Github and study it or do with it whatever you like.

CuteContacts-iOS7: Cloning iOS7 Contacts application UI in Qt/QML

As you might know I am interested in figuring out the ways for making native or almost native looking apps for iOS and Android with Qt/QML.

So I have started a project on GitHub for trying one of the ways. CuteContacts-iOS is an attempt to use customized QtQuick Controls for cloning the iOS7 standard Contacts app UI. It is not intended to be a real final application, nor a guidebook for correct coding. It is a proof of concept for the UI level only.

Pasted Image 5 16 14 0 01


If the projects succeeds in full, it might evolve into a library of controls or framework, but that’s a secondary goal. Primary goals are:

  • To go the edge of what’s possible in looking iOS7 native and to have a working native or almost native looking demo.
  • Evaluate possibility for prototyping iOS7 apps in QML. QML is extremely powerful tool for super-fast UI prototyping, but if 90% of time will be taken by recreating basic controls experience..
  • To identify impossible or particularly difficult UI bits and draw Qt Project team attention to these

How you can help

Well, just join the project and submit pull requests. Most of all it would be great to have some UI-aware mind helping. I have fun solving the principal issues and figuring out the ways for cloning UI and animations precisely, but I have problems with understanding what exactly it should be like: exact color values, exact sizes in pixels and so forth. And most of graphics I just cut out of the popular iOS mockup template Getting advice and contribution in all things UI would be very welcome. Coding contributions would be great too naturally.

Principal difficulties I have uncovered by now

The project is just starting and many discoveries are ahead, but a couple of issues I don’t have easy answers for are uncovered already.

Unpaintable “under status bar area”

Some iOS7 animations such as opening a Search box editor in the title bar require animating and painting under the status bar (area with the phone signal). There is no way to do it in pure QML as this area is either beyond the QML control completely or we have to take the whole screen and somehow paint status bar ourselves. Has anybody got an idea on how to ask iOS paint it’s standard status bar over the QML canvas

Color of the blinking cursor in the text editor

There seems to be no QML way to control it. Do you know how to adjust it from C++?


Your opinion

What do you think? Does the project make sense to you? Would you contribute and how to make it easier for you to do so?

Qt on iOS and Android. Looking native today. Or maybe tomorrow

That’s a long post about what could be the ways for making a native looking and feeling, and behaving Qt app for iOS and Android, so here’s a table of contents:

Qt and mobile apps

Coming from strong Nokia background I like Qt and mobiles. I used to be a Forum Nokia Champion, Qt Ambassador, created a number of Qt/QML apps for Nokia N9 and Symbian, possibly created the first ever 3rd party app available from MeeGo, Symbian and Android app stores and built from the same source code. Nowadays I am spitting out Jolla Sailfish apps (including the app more popular than the system Clock app) with the machine gun speed just because I love to see power of Qt and QML come to action on the fully-Qt device.

I am also a UI standards maniac (not necessarily a succeeding one) and it drives me crazy that I cannot use my favorite Qt and QML for building mobile apps for mass market (read: Android and iOS), now that it is technically possible, but in practice only low level graphics examples exist and nobody seems to care much about native or native-looking toolbars, gestures, sharing dialogs, integrating to notification services, you name it.

Right now I am flying for a New York reunion of my day job company (BTW, have a look at pretty cool interactive images service we make, sure we have mobile apps for creating these on the go too) and drafting this post for outlining a set of experiments to proof or decline the ability to create native-looking iOS and Android apps already today or tomorrow. I will probably try implementing a couple of these and some will be beyond my skills. So if you are into the same stuff, grab a topic, do an example on github and post it to comments, I’ll add it to the post.

What’s needed for app to be native-enough

So what’s needed for an app to be native enough. Two things: native look&feel and integration to the system services.

Native look and feel

Buttons, toolbars, gestures (e.g. iOS 7 Back gesture), native text input, view transitions, theming according to the current device theming. Sure it’s better for these to be fully native, but looking at what modern mobile HTML5 app frameworks are able to achieve, I think it’s okay at least for now if your app will look almost native. For example, if you implement view transitions yourself so that they look almost native and make buttons that look like the default phone theme only, I won’t be ashamed for shipping such an app to app store. As a rule of thumb: if you would feel okay showing the next Instagram-Twitter-Foursquare app done this way to potential investors, I’d say UI is looking native enough.

Integration to the system services

There are non-visual or partially non-visual services that user got to expect from the native apps nowadays (and not immediately supported by Qt). Two prime examples are system sharing sheets and system accounts integration (logging in/signing up with Facebook, Twitter, Google+). As the secondary examples I would add being on the receiving side of the sharing interaction and working in the background when started by the system notifications service or just because your app is registered for the background execution. Sure you could add many more examples, but if the ones above are covered, everything else should be doable to and you will probably be able to modify the existing proof-of-concept demos for it.

What’s possible for making the native-enough app

Native look and feel

There is a number of approaches available:

Plain Qt Quick

Plain Qt Quick

You get a rectangle and you draw there whatever you like. That is the way the current most cool mobile Qt demos are made, performance seems to be good enough for cool effects and fast animation on all the relatively modern devices. That could be a good approach for creating a cross-platform mobile game nowadays where you anyway are likely to have non-system looking controls and not much system interaction.. except for in-app purchases.

  • Pros: You can use power of the full Qt and QML, manipulate your C++ objects and QML and create whichever effects you want easily
  • Cons: If you are not creating just a demo game, cloning system toolbars and view transitions could be a daunting and boring task. Possibly an easy one, possibly a complex one

Qt Quick Controls

Qt quick controls

That is the primary way forward for Qt for Android. There is an effort led by Bogdan Vatra for making existing Qt Quick controls look real native and even fetching colors and font sizes from the system theme. The problem is that most of these goodies are [probably] coming in the end of 2014 the earliest and are for Android only anyway. Meanwhile you can grab the current, quite desktop-looking controls and with a bit of hammer and swearing make them look good enough for you. There is even a couple of open source projects aimed at it.

  • Pros: Full Qt/QML power is still here, you will definitely find at least PageStack and Page elements useful, possibly some controls won’t look that bad.
  • Cons: You won’t get theming for free, possibly making even semi-okay looking controls will be difficult, native looking transitions and gestures will also be on you

HTML5 with C++ interfaces

HTML with large QML part

Qt 5.2 SDK already includes an HTML5 app template and, well, it is pretty much just a Webkit view with HTML inside, so you can use some modern mobile app frameworks for the native-looking buttons and toolbars. Advantage you get from using these frameworks in the HTML only mode is [potentially] easy integration to the C++ side on your code. I think you could access C++ side objects injected to HTML or made accessible by it (e.g. Settings or file system or your proven network comms engine). And/or you can go the other way around and modify web page DOM elements from C++.

  • Pros: Native-enough look nearly for free. You can still use your Qt libraries and shift much of the complexity to the Qt side
  • Cons: No QML, Qt-HTML integrations could be difficult and unusual (e.g. could signals and slots be used anyhow?), no good debugging and profiling tools

HTML5 with the large part painted in Qt/QML

HTML with large QML part

A variation of the above for the apps centered around large main controls such as lists, map of the local restaurants or a painting board. It is likely to be possible to paint these using Qt/QML though performance and ease of debugging of such an option are to be studied yet. Controling lifetime of such objects could also be tough.

  • Pros: You get native enough-looking controls nearly for free while using Qt/QML exactly where it matters most and where you want to polish the UI.
  • Cons: Debugging and optimization could be difficult, running two JavaScript interpreters and passing data/signals back and forth through several layers (or some side bus) could be challenging

HTML5 inside QML

HTML5 inside QML

That is sort of a reverse approach. You can have a QML app that devotes 100% of it’s space to a web view or you can even have a non-visual QML component running side by side with the web view instantiated the C++ way. Then you can paint 100% of UI using HTML5 UI frameworks while having app logic in QML. If you go one step further, you can even create a whole presentation layer in QML that just maps itself into as lightweight as possible HTML5 UI.

  • Pros: Native enough-looking controls from HTML5, all the logic in Qt/QML, property bindings included
  • Cons: It could be tough to establish one-two one mapping between QML and HTML5 when reading and writing data

QML inside HTML5 inside QML

QML inside HTML5 inside QML

I.e. main UI list done in QML injected into web view created by a QML app. Just because we can 🙂
I am far from being sure it is easy to do, but if it happens to be easy, you could get the best of both worlds: controls and view interaction only from HTML5 frameworks, power of QML logic and graphics for everything else.

  • Pros: HTML5 only where it’s really needed (just for native looking controls/transitions) and nothing else. Everything else in Qt/QML
  • Cons: Could be too tough to do that many levels of injection

Real native manipulated by QML

Real native manipulated by QML

QML is not the only Qt way for contracting UI. You can still use a form designer for getting a QtWidgets app and manipulate the generated form from C++ (technically from QML too though you are not likely to do it).

Nowadays both Android and iOS have a way to define UI declaratively and certainly you can use native code for adding more controls. Well, you could define such layouts in the native tools and then instantiate and manipulate them from Qt/QML, possibly even painting a couple of particular controls yourself.

  • Pros: Native look and feel, no compromises whosoever!
  • Cons: Quite platform-specific way for integration, injecting your own controls inside can be tough

Integration to the system services

That is the area I am not really familiar with unfortunately so can’t outline many approaches. I only know that it should be possible to communicate with the Android side via JNI and some way for accessing iOS APIs should also be possible. How easy or hard it is and whether you will be able to use e.g. platform-specific Facebook SDK for logging people in is to be studied.

Experiments to perform

So here is a list of proof of concept demos I think are needed for validating the approaches outlined. Once I implement some of them or figure out an existing demo about the same, I’ll add the links to here. Demo projects could about whatever topic, I guess a basic Flickr browser could make a good reference app.

  1. Looks and feel
    1. Plain QML or plain QML + just PageStack from Quick controls. Just make them look native(ish)
    2. QtQuick controls styles to look like iOS/Android
    3. QtQuick controls styles to look like iOS/Android
    4. HTML5 (with some mobile UI framework) + interaction with the Qt objects
    5. HTML5 with some area inside painted by Qt/QML, ideally a couple of different controls in a couple of different pages
    6. HTML5 inside QML app and manipulated from QML
      • And QML inside HTML5 inside QML
    7. Native iOS layout(s) manipulated from Qt
    8. Native Android layout(s) manipulated from Qt
  2. System integration
    1. Logging in with the system integrated Facebook/Twitter/Google+ (probably many different platform-specific projects)
    2. Passing link/photo to Android sharing framework
    3. Passing link/photo to iOS sharing framework
    4. Receiving link/photo on Android from sharing on Android
    5. Receiving link/photo on iOS. Okay, that’s not very important as I think on iOS the sharing source has to exactly know your app for sharing to you
    6. Sharing link/photo using exactly Facebook/Twitter/G+ SDKs for fully optimized native look
    7. Waking up on system notifications
    8. Waking up on geofencing event or something like that
    9. Just running in the background sometimes

Your opinion

What do you think? I created this list first of all for my own understanding. I am likely to actually try a couple of approaches, but will probably stop once I figure a good enough solution for some real app to make or if I give up due to the complexity. Then this proof-of-concept catalog could continue only if there’s an active interest from somebody to make consumer grade Qt apps a reality on iOS and Android.

Does this list of approaches make any sense to you?
Do you know of some existing projects already trying these? Is something important missing?

Do you think the whole goal of making cool looking Qt apps for iOS and Android is worth studying at all while there are good 100% native platform-specific tools already and even HTML5 for those into the cross-platform UI dream?

Log4Qt for Jolla Sailfish OS and in general

I had troubles with logging from my Qt code efficiently, so took an effort to find a good and flexible logging framework that works. Log4Qt is very powerful and works well, but lacks docs and examples. So I created a sample project that uses it and tried commenting it as much as I could. It is a Jolla Sailfish OS app, but with very small changes same should work for other platforms as well (Sailfish OS is pretty much just Linux + custom QML controls + requirements for the app binaries/data to be located in specific places).

If you are in a hurry, just go grab the code on github. If you are making Jolla apps, you can use the HelloWorld Pro wizard for renaming the project into my-cool app. The rest of this post is just an overview of what happens in the code and repeats comments quite a lot.

Why logging example

Logging in the Qt world is easy, but not really configurable. Here’s how you do it typically in c++:

and here’s how you do it in QML:

Most of the time I just comment out logging statements when there is too many of them. You can also stream the logs to file via qInstallMessageHandler() and there are some code examples for it.

That works great for normal development, but always takes time when you want to log the particular code unit without too much noise from the other ones. In Qt 5.3 situation will become better with the addition of configurable categories, you will be able to enable or disable whole groups of logs yet I still find it not flexible and configurable enough. Also Jolla Sailfish OS which I care at the moment most about is still on Qt 5.1


Log4Qt is a port of a [not the latest version of the] popular Log4J library (that I happen to use too). It lets you be very simple or as advanced as you like: you can set priorities on many levels, stream logs to files, syslog, console, database even network and configure it all at run-time or via the settings files. There is only one problem: a lack of examples and documentation (docs are pretty much the ones that were ported from Log4J code).

Well, so I created a reference copy-pastable example project demonstrating many of the project features in [hopefully] the proper way. That is the project for Jolla Sailfish OS on which I focus lately, but with very minimal changes it should work for any other platforms as well (join to create ports or expand the current example to multiple platforms).

Features demonstrated

  • Multiple logging destinations: console, file (with daily log files), syslog
  • Different logging levels for different C++ classes and QML objects
  • Different logging levels for the different destinations (e.g. only ERROR+ messages to syslog, and DEBUG+ to console)
  • Configuration via stand-alone .conf files
  • Prioritized .conf file selection (falling back to default settings unless user puts another .conf file to a particular dir)
  • Different default configurations for the debug and release builds
  • A project structure that makes sense for the production projects: engine with C++ objects, app with QML objects, c++ tests and QML tests with little dependency on Log4Qt
  • A project that is good enough for passing Jolla Harbour criteria and getting to the app store
  • A separate “pseudo app” project that can be installed to the user’s device for generating more logs from the main app (basically just drops another .conf file to the proper directory)

How you use logging in your app

The easiest way to get started is to just clone log4qt-demo project. You can use rename-to-my-project.py script for renaming the project into my-cool-app, see HelloWorld Pro docs on how to do it.

Starting with Log4Qt one class at a time

Demo project configuration captures all console.log, qDebug(), qWarning() messages to the Log4Qt streams as a logger (unit of logging) called “Qt”, so you can continue using your current logging practices while introducing new logging facilities step by step

Logging from c++ objects

Then for the classes you want to log you state the following macro in their cpp implementation:

and from the class’s function you log one of the following ways

Logging from where these classes are used

For streaming syntax support you need to have the following in the class implementation:

And then from you main.cpp or from wherever else you can do, for example, the following:

Logging from QML

For intercepting QML logs, app part of the demo project injects QmlLogger into the QML engine. Then inside QML you can make as many loggers as you like (I recommend creating one per QML source file) and use them in the following manner:

File-based configuration

There are a couple of demo config files in the project.
What you mostly pay attention at during daily work is the bottom part where you shut up certain logging units or let them speak at the default DEBUG level:

How it is structured

There are two completely independent projects in the repository: the main one consisting of log4qt itself, engine, app, qmlTests, cppTests and increasedLoggingPackage that is sort of a fake app that makes main app produce more logs when installed (e.g. to the user experiencing tech issues).

Project structure


  • increasedLoggingPackage is a completely stand-alone micro-project that just happens to exist in the same source tree. You build it separately and send to user if you want his app installation to produce more logs
  • Note that qmlTests project also exports a shell script to /usr/share/tst-harbour-log4qtdemo-qmlTests/runTestsOnDevice.sh that runs both cppTests and qmlTests. You can check HelloWorld Pro docs to see how to run it straight from Qt Creator.

Logging streams

Here’s what sort of structure a demo .conf file creates for your project:


You can have as many loggers as you like. I find it convenient to have one logger per class + logger called “Qt” that intercepts console.log and qDebug()/qWarning() streams. Then everything gets to rootLogger and spread further to so-called appenders that write to console, file or syslog (journalctl in Sailfish OS case).

Other things to note

  • Log4Qt is fetched via git subtree straight from https://gitorious.org/log4qt/ that is a slight variation of original http://log4qt.sourceforge.net/ that I chose for support for colored console output (that happened to be not working for *nix) and some other modifications that seemed to be maintained in 2014. That is good enough for my purposes, you may like to use the original Log4Qt in your projects.

Where help is needed most

There is a number of TODOs in the code and in github readme. The main need is in creating ports of the solution that won’t be Sailfish OS specific. You can create simple ports or ideally improve the current project so that it builds and runs for desktop as well

Your impressions

What do you think? Makes sense? Do you want to improve it? Go fork a github project and propose pull requests or create ports