Coding for fun: A Facebook Photo Connection Graph

Apparently I haven’t blogged in nearly 5 years, wow! Most of my coding for fun in the last few years ended up being on internal systems to my previous company. Well all that’s in the past now, I’m about to start an adventure of traveling for 6 months around Central/South America and South-east Asia.

But just before that, had a couple days downtime so thought I would learn a little javascript and D3. You can see the result on:

http://francis.giannaros.org/fb-graph/
(works in Chrome/Firefox, you have to click ‘Accept’ on the Facebook popup)

Basically it will give you a graph visualisation of who you are tagged with on Facebook, and how your friend tags relate — at least all the ones available from the Facebook graph UI.

You can use the date slider at the top to restrict the timeline — it’s interesting to see how people come and go in your life, at least as far as Facebook photos are concerned.

Looking forward to future fun coding, maybe more directly in an established free software project again!

Facebook Photo Tag Graph

 

 

 

Qt @ Embedded World 2015

Yesterday, we ended a great 3 days at Embedded World 2015 (Feb 24-26)  in Nuremberg, Germany. Considered the largest embedded development trade show, the event organizers estimated 30,000 exhibition visitors, over 1,500 congress participants and around 900 exhibitors from over 35 countries.

Personally, this is my 7th Embedded World with Qt and I have to say that this one has been our best one yet. I know, I say that every year, but the good thing is that we keep getting better every year; larger booth, more demos, more visitors, more companies sold on the fact that Qt is the best solution for embedded software development.

We showcased Qt’s strength in embedded software development with a combination of demos and customer projects focused on Qt in Automotive, Qt in Automation, Qt in IoT, all telling/showing the story of how Qt is used in a real-life reference project or product. Qt’s role in embedded software development was further told by our “Under the Hood” demos highlighting several specific features and functions such as:

  • Qt and OpenCV: Demonstrating how to easily & efficiently integrate computer vision or other computation or image processing algorithms with Qt Quick 2 and Qt Multimedia.
  • Qt Creator in Action – Debugging and profiling: Demonstrating the power of Qt Creator IDE for one-click embedded deployment, and on-device debugging and profiling, Qt Quick Designer
  • Qt UI capabilities, Qt WebEngine, Virtual Keyboard, multimedia capabilities, etc.
  • Qt for QNX: Qt 5 applications and UIs on QNX Neutrino
  • Qt for VxWorks: Qt 5 applications and UIs on VxWorks 7

This year, we had, like in the past 3 years, the live coding theater running daily on the hour from 10:00-16:00. We mixed it up this year with 3 different sessions: Introduction to Device Creation with Qt, Functionality Meets Productivity – Qt Developer Tools and Qt Features Overview. Thanks to our fearless and dedicated presenters. Well done!

I was the most happiest to have a large portion of our booth demos come from our Qt Partners. They had an abundance of industry-specific demos in automotive, automation and IoT. Qt’s story was made stronger with our partners demonstrating the power of Qt and its many uses in the embedded space. Thanks to e-Gits, basysKom, Froglogic, KDAB, Adeneo Embedded and ICS for being with us.

Without more hoopla, below are a few pictures from our booth and demos. If you came by our booth, thanks for visiting us! I would also like to say Thank You to The Qt Company staff onsite and again to our partners. Until next year.

 

 

Qt Embedded World 2015 Qt Embedded World 2015 Live coding theater - Qt Embedded World 2015 Qt Embedded World 2015 Qt in Medical & Qt in Marine Navigatiion Qt Machine Vision - OpenCV Nautical UI - Qt Partner KDAB Testing tool -Qt Partner Froglogic Automation - Qt Partner basysKom Automotive - Qt Partner - e-Gits Automotive - Qt Partner ICS Automotive - Qt Partner Adeneo Embedded Automotive - Qt on Magneti Marelli

New Qt Wiki Now Available

We are continuing our site unification to qt.io and we have now migrated the content from qt-project.org and today opened up the new Qt Wiki under qt.io. We invite all of you to start editing the new Qt Wiki under qt.io using the new MediaWiki implementation.

This is the first phase launch of the wiki under its new home, and therefore, you may find some things currently missing or not quite like they were before under qt-project.org. There are a variety of reasons for the latter. One main one is that our goal has been to make things easier than they have been before, providing wiki users a better editing experience, as well as more flexibility.

MediaWiki is is one of the standard wiki formats, which is a more familiar format to use for many than the wiki that has been used under qt-project.org.

MediaWiki benefits:

  • Open source platform
  • Active development of the platform
  • A wide range of plugins to extend the wiki functionality
  • Version control
  • Better tools to follow and automate working on the wiki

What you will find different

In this new wiki, we will all be able to keep track of active editors directly in MediaWiki where it will be easier to follow who has edited what and when, as well have better control of versions.. Unfortunately, in this first phase, you will notice that the edit history of past articles has not been migrated over. As the old wiki system (Expression Engine) and MediaWiki are very different it has proven very difficult for the migration team to combine history from the old system into the new one. Our team will continue to look at this as we move along to see how we can best manage this. However, we do feel that manage wiki posts and edits from now and in the future will be much better, which outweighs in part the possible loss of past article history.

Using Qt Account for editing

The biggest change that the wiki introduction brings to you as a user, is that we are moving to using Qt Account as the identity and login service for the wiki.

Qt Account is in essence the gateway to what we are building as a new Qt developer portal. We have already started using it for commercial evaluators and customers in the past year. Currently, the Qt Account web portal provides users with license information, account and payment options. It is also provides access to The Qt Company Support Center where commercial users can submit support issues.

This is just the beginning, however. Our goal is to add valuable Qt information and resources, early access benefits, programs and the like into the Qt Account developer portal, making it your one-stop-shop for up-to-date Qt info and goodies.
I’ll say something in big bold letters here:

When you start to edit, you will need to create a Qt Account. Please make sure to use the same email as you had on qt-project.org, that way you will get your nickname to come along with you.

Previously you logged into the wiki with your qt-project.org account details. Now you will be directed to the Qt Account login page.

If you do not yet have a Qt Account, you can create an account from the login page. If you have been active on qt-project.org, your username has been reserved for you, if you use the same e-mail address as on qt-project.org.

Our next item to migrate over is the Forums. When they move, they will also use Qt Account for login services. This is also the reason to use the same email on Qt Account as you did in qt-project.org. When the forums migrate under qt.io, your nickname and posts will move with you. However, please note that if you use a different email, we can’t connect your nickname automatically.

Migrated content

The old wiki contained over 3000 pages, which were processed and migrated to the new wiki. Some of the pages are quite old, but we know people work on old platforms and with old software releases, so we didn’t intentionally delete pages.

Some old pages were not migrated, but that decision was based on browsing data. If the page had very low, or no, visitors in the past year, it was deemed to be of low value and sadly left behind.

As with any migration there are some few issues. We are aware of challenges in at least the following:

  • Image links are broken.
  • Code blocks have been split into parts
  • Special characters have been encoded as HTML character codes
  • The way Category pages used to work is not the way MediaWiki works, so some Category pages contain double information

Therefore, we would be grateful if you could help us with the following:

Cleaning up the content

If you maintain or edit a page(s), please have a look next time when you edit to see whether there are issues on the page. Open the same page on the old wiki and take a look if something is missing or if it looks wrong, and please fix it.

We opened a wiki page where you can mark your page updated. Once you have looked at a page and edited it to an up-to-date state, please take a minute to add it tothe page list here. (I will be looking at the page edits and updating the page, but I do appreciate if you help me out there)

A helpful page that the wiki itself provides is the list of pages with broken links. If you can help out, you can go through the pages listed there and grab the content/links from the old wiki and upload it to the new wiki. We now have proper image uploading in the new wiki, a great new benefit. Also if you do not wish to upload images to the Qt Wiki, we enabled linking to external images, by just pasting the direct image link to the wiki text, this should be practical for logos and images which may change.

Also, if your favourite page did not make it to the new wiki due to very low visitor count in the past year, we encourage you to re-create the page on the new wiki.

Old wiki still available

The old wiki will stay open for reading until the end of March. That means that you have a month to make sure your favourite pages have not lost content in the move.

After that, the old wiki will be retired and redirects will be set in place.

We really appreciate your help in cleaning up the content and also welcome your feedback. It is lots of content, so we can’t do it alone. Thanks for your help and support!

Important Qt-project.org Migration to qt.io Info

Today, we will go live with the new Qt Wiki on qt.io with content migrated from qt-project.org. Before we do that and as we reach a major milestone in this migration project, I wanted to explain a bit on what are the biggest changes you will see with this overall migration project and what it means to you and also new functionality and things to expect in the future.

The biggest changes you will see are:

  • The current gamification, points system from qt-project.org (DevNet) will change
  • “Qt Account” will be the new login service to access and edit the wiki and forums
  • The services will be on new platforms

Different point system

As we change the wiki and forum platforms, some things will change.

One of these is the current points and levels system. In the new site, we will not use one point system to denote your activity within the qt.io site. Instead, each service (wiki & forum) will have their own lists of activity.

In the forums, which have been the main source of points in qt-project.org, the new system has a Reputation score, which works more based on people liking posts and answers, a more people-centric approach. Initially, there won’t be point levels. As we move along, we will introduce other features and possible programs to allow for more interaction.

A great thing about the new system is that it provides badges and groups, which allow us to have many types of engagement and recognition-based on forum activities. We will migrate the badges from the old system, so those won’t be lost. However, as it is a big task, those will not be there on the first day we switch over to the new forum. (BTW: we are estimating that the migration will happen sometime next week. But, please bear with me, as some things in the technical world are just beyond our control.) The new forum will provide a more flexible badge system overall, so we will be working more with badges in the future.

In the new wiki, the system will keep track of who edits and creates pages and keeps lists based on that. The main difference is that these statistics will not be directly added to an overall point system, at this point.

To sum it up, in the future there won’t be designations like ‘Ant farmer’, but you will have a reputation score on the forum and an edit history on the wiki. The main goal of knowing who is an active community member will be met; the way it is done will be slightly different giving us more flexibility to add more interaction possibilities as we move along and as we hear feedback and ideas from the community.

As mentioned, we do have plans of a new overall unified-level point program system, where those that are truly active within our channels will benefit greatly. This will span both commercial and open source users where the goal is to connect to all our users and provide valuable interactive information. However, this is still in the planning stages and we will communicate those as we move along. For now, our updated services like wiki and forums will have their own point system and history overview.

Profiles & Qt Account as your login service

One of the biggest changes for you as a user is that we are moving to using Qt Account as the identity and login service for the new wiki and forums in qt.io. The logic to having a single service for logging in is simple; no need to have separate logins for different services.

If you currently have a user profile under qt-project.org, your personal information contained in it, such as detailed contact information and social media accounts, will unfortunately not be migrated over at this time. We will, however, migrate and match all existing nicknames/usernames from the current system and peg it to your Qt Account. We are not throwing that information away, if at some point in the future we enhance the Qt Account profile to include the data, it can be added from the qt-project.org database we are keeping in backups.

Qt Account is in essence the gateway to what we are building as a new Qt developer portal. We have already started using it for commercial evaluators and customers in the past year. Currently, the Qt Account web portal provides users with license information, account and payment options. It is also provides access to The Qt Company Support Center where commercial users can submit support issues.

This is just the beginning, however. Our goal is to add valuable Qt information and resources, early access benefits, programs and the like into the Qt Account developer portal, making it your one-stop-shop for up-to-date Qt info and goodies.

IMPORTANT: Please make sure to use the same email address as you had on qt-project.org, that way you will get your nickname to come along with you to Qt Account and the new services.

New look and feel & new platforms

As always when moving to a new platform, the services will look and feel different. We are not at this point in a final stage with the design. That will get incremental updates as things move forward. We know it takes some time to get used to a new site, so please take it easy and explore the new services as they migrate over.

The reasons for going to new platforms are many.

In order to be able to provide a better experience to our users, we had to clean up some of the technical backend headaches caused by the current system. New platforms will allow us on the backend side to better support the services and stay up-to-date with new requests and platform development in order to add more functionality as we and you see fit.
The new forum platform, NodeBB, has a very active community and provides the following benefits:

  • is usable directly on mobile devices, as it supports responsive design out of the box
  • has an active open source developer community around it
  • supports plugins, and has many ready-made ones
  • plug-in creation interface is easy to use
  • has a clean modern API
  • has post tagging out-of-the-box
  • has better spam control

For the wiki, the new platform, MediaWiki provides various benefits mainly because it is also an open source solution with a large community. I will provide more information on the wiki migration in another post coming soon.

Feedback

We know that getting used to a new platform and site takes a while. When you encounter something that you find annoying, and if it is a bug, please file a bugreport, but if it is an inconvenience or a feature request, please start a discussion in the Website discussion forum.

Thanks for your help and support during this migration process. All feedback welcomed!

QmlBook Making Progress

It has been a long time since the last update of QmlBook was announced – but the project is definitely live and kicking. Jürgen has put in a lot of great work into the contents and gotten the collaborative work over on github started. To simplify the publication, the contents has been moved to github hosting, but you can still use the old qmlbook.org (and qmlbook.com) addresses to get there.

qmlbook-screenshotThe reason for the standstill on the qmlbook.org/com sites, and much of the perceived lack of progress is due to my personal time situation. Small children and family life takes time, as does my work (which is awesome and includes Qt/QML – go Pelagicore). Unfortunately, I’m a bit of an optimist, so I want to, and truly believe that I will have time to work on side projects such as this book. But the 24h/day limit sucks, so sometimes I realize that I fail to do so.

However, this is not a post where I complain over my own situation – instead – I want to thank all the contributors who keep feeding us issue tickets via github! I would also like to thank our readers – it is great to hear from you! And finally, I’d like to thank Jürgen who has put down a lot of work and kept the project moving forward.

It is not my intention to leave this project, I’m just short on time at the moment due to other awesome things in my life (kids, wife, work) – I’ll be back!

Planning for the Unknown Unknowns

Over many years of developing software and building user interfaces, I’ve seen numerous shifts in technology and been present for multiple evolutions in the way developers craft quality software.

Qt 5.4.1 Released

Today we have released Qt 5.4.1, the first patch update to Qt 5.4. In addition to improvements and fixes to Qt functionality it also packs new Qt Creator 3.3.1.

Qt 5.4.0 released in December introduced many features such as our new Chromium-based Qt WebEngine, WinRT support (including Windows Phone), and several Graphics improvements. With Qt 5.4.1 we are providing a good set of bug fixes and enhancements – thanks to all the feedback and reports we’ve received.

Qt 5.4.1 restores binary compatibility for Qt 5.3.2 (and the Qt 5 series) on Windows. Unfortunately Qt 5.4.0 broke binary compatibility on Windows when using MSVC 2012 or MSVC 2013, which is now fixed in Qt 5.4.1, and thus it maintains backward and forward compatibility with the Qt 5 series (except for Qt 5.4.0). Qt 5.4.1 also fixes many of the known issues of Qt 5.4.0, including building Qt on Linux without dbus (QTBUG-43205). Starting with Qt 5.4.1, QtDBus is enabled for all builds.

Other important fixes in Qt 5.4.1 include enabling JIT by default in the Qt Quick Engine (QTBUG-43171), a couple of critical fixes to OpenGL (QTBUG-43178 and QTBUG-43318), and fixes to Mac binaries (QTBUG-42594, QTBUG-43100). Qt 5.4.1 also provides a large number of improvements to WinRT (for example QTBUG-41769, QTBUG-43862, and QTBUG-44196), and adds support for Windows 10 Technical Preview (QTBUG-43413).

The device creation reference stacks for embedded Linux and embedded Android have also been updated to use Qt 5.4.1. There are some improvements in functionality, for example better support for compiling projects using embedded Linux toolchains and having add-on modules built into the image included in the generated Qt Creator custom Kit.

The full list of important changes can be found from the change files for each module.

The packages of Qt 5.4.1 also include new Qt Creator 3.3.1. See the blog post about Qt Creator 3.3.1 for the main improvements.

If you are using online installer, Qt 5.4.1 and Creator 3.3.1 can be updated using the maintenance tool. Offline packages are found from the Qt Account (for Enterprise users) and from the Download page (for Community users).

Join the live webinar

Please join us for a live webinar on Wednesday, 25 February where we will present an overview of Qt 5.4. We’ve spent countless hours ensuring that Qt 5.4 is our best release yet, and we can’t wait to show you what we’ve done! A copy of the recording will be sent to all webinar registrants, so please feel free to register even if you can’t attend due to limited live seating. Register now!

Qt Creator 3.3.1 released

We are happy to announce the release of Qt Creator 3.3.1. This release of Qt Creator is a pure bug fixing release. Please have a look at our change log for details.

Qt Creator 3.3.1 is now available for download on qt.io. Please post issues in our bug tracker. You also can find us on IRC on #qt-creator on irc.freenode.net, and on the Qt Creator mailing list.

Swift 3.0-beta1 Released

We’ve just released a Swift 3.0 beta. A fuller list of new features is available on the download page, but highlights include file transfer support, keyword highlighting, nuisance user blocking and seamless multi-person chats. We encourage everyone to get the new build and try it out, and tell us about any bugs they should come across as we work towards release candidates and a final release.

Qt Weekly #27: WiFi networking support on embedded devices

As a part of the Qt for Device Creation offering we provide several
helpful add-on modules that assist in creating applications for embedded devices. In this blog post I would like to demonstrate some of the features supported by the B2Qt WiFi add-on module.

What is it?

The B2Qt WiFi module provides APIs for connecting embedded devices to a wireless network. There are C++ and QML APIs available for managing wireless network connectivity, scanning for wireless network access points, retrieving information from these access points, monitoring for network state changes and more. The API allows you to manage when and to which network to connect, and when to go offline.

Overview of the API

The module consists of 3 classes:

  • (Q)WifiConfiguration – Used to define a network configuration.
  • (Q)WifiDevice – Represents a physical device.
  • (Q)WifiManager – Main interface to the WiFi functionality (Singleton).

How to use it

Here is a code snippet in QML demonstrating how easy it is to connect a device to a wireless access point named “bus-station-wifi” that uses the WPA2 security protocol:

    import B2Qt.Wifi 1.0

    WifiConfiguration {
        id: localConfig
        ssid: "bus-station-wifi"
        passphrase: "mypassword"
        protocol: "WPA2"
    }

    Connections {
        target: WifiManager
        onBackendStateChanged: {
            if (WifiManager.backendState === WifiManager.Running)
                WifiManager.connect(localConfig)
        }
        onNetworkStateChanged: {
            if (WifiManager.networkState === WifiManager.Connected)
                print("successfully connected to: " + WifiManager.currentSSID)
        }
    }

    Component.onCompleted: {
        if (WifiManager.backendState === WifiManager.Running) {
            WifiManager.connect(localConfig)
        } else {
            // starts initialization of wifi backend
            WifiManager.start()
        }
    }

And the following code illustrates how to achieve the same in C++:


class WifiConnectionHandler : public QObject
{
    Q_OBJECT
public:
    WifiConnectionHandler()
    {
        m_config.setSsid("bus-station-wifi");
        m_config.setPassphrase("mypassword");
        m_config.setProtocol("WPA2");

        m_manager = QWifiManager::instance();
        connect(m_manager, &QWifiManager::backendStateChanged,
                this, &WifiConnectionHandler::handleBackendStateChanged);

        if (m_manager->backendState() == QWifiManager::Running) {
            m_manager->connect(&m_config);
        } else {
            m_manager->start();
        }
    }

protected slots:
    void handleBackendStateChanged(QWifiManager::BackendState state)
    {
        if (state == QWifiManager::Running)
            m_manager->connect(&m_config);
    }

private:
    QWifiManager *m_manager;
    QWifiConfiguration m_config;
};

The previous examples showed how to connect to a network for which the configuration is known beforehand. As mentioned earlier, the WiFi module can also be used to scan for available WiFi access points. In the next example we use the scan results and present them in a list where the user can select which network to use.

    Binding {
        target: WifiManager
        property: "scanning"
        value: WifiManager.backendState === WifiManager.Running
    }

    WifiConfiguration { id: config }
    ListView {
        anchors.fill: parent
        spacing: 8
        model: WifiManager.networks
        delegate: Row {
            spacing: 10
            Text { text: ssid }
            TextField { id: passwordInput }
            Button {
                text: "connect"
                onClicked: {
                    config.ssid = ssid;
                    config.passphrase = passwordInput.text
                    WifiManager.connect(config)
                }
            }
        }
    }

Here you can see a screenshot of a more advanced application running on a Nitrogen6_MAX board that utilizes WiFi API for wireless network setup.

wifi-settings

For more information check out the documentation.

Trojita 0.5 is released

Hi all,
we are pleased to announce version 0.5 of Trojitá, a fast Qt IMAP e-mail client. More than 500 changes went in since the previous release, so the following list highlights just a few of them:

  • Trojitá can now be invoked with a mailto: URL (RFC 6068) on the command line for composing a new email.
  • Messages can be forwarded as attachments (support for inline forwarding is planned).
  • Passwords can be remembered in a secure, encrypted storage via QtKeychain.
  • E-mails with attachments are decorated with a paperclip icon in the overview.
  • Better rendering of e-mails with extraordinary MIME structure.
  • By default, only one instance is kept running, and can be controlled via D-Bus.
  • Trojitá now provides better error reporting, and can reconnect on network failures automatically.
  • The network state (Offline, Expensive Connection or Free Access) will be remembered across sessions.
  • When replying, it is now possible to retroactively change the reply type (Private Reply, Reply to All but Me, Reply to All, Reply to Mailing List, Handpicked).
  • When searching in a message, Trojitá will scroll to the current match.
  • Attachment preview for quick access to the enclosed files.
  • The mark-message-read-after-X-seconds setting is now configurable.
  • The IMAP refresh interval is now configurable.
  • Speed and memory consumption improvements.
  • Miscellaneous IMAP improvements.
  • Various fixes and improvements.
  • We have increased our test coverage, and are now making use of an improved Continuous Integration setup with pre-commit patch testing.

This release has been tagged in git as "v0.5". You can also download a tarball (GPG signature). Prebuilt binaries for multiple distributions are available via the OBS, and so is a Windows installer.

We would like to thank Karan Luthra and Stephan Platz for their efforts during Google Summer of Code 2014.

The Trojitá developers

  • Jan Kundrát
  • Pali Rohár
  • Dan Chapman
  • Thomas Lübking
  • Stephan Platz
  • Boren Zhang
  • Karan Luthra
  • Caspar Schutijser
  • Lasse Liehu
  • Michael Hall
  • Toby Chen
  • Niklas Wenzel
  • Marko Käning
  • Bruno Meneguele
  • Yuri Chornoivan
  • Tomáš Chvátal
  • Thor Nuno Helge Gomes Hultberg
  • Safa Alfulaij
  • Pavel Sedlák
  • Matthias Klumpp
  • Luke Dashjr
  • Jai Luthra
  • Illya Kovalevskyy
  • Edward Hades
  • Dimitrios Glentadakis
  • Andreas Sturmlechner
  • Alexander Zabolotskikh

What's coming to Green Island: part 2


In the previous installment I forgot to post a screenshot of multiple output windows.

Here it is:


The first big chunk of code for multiple output support was recently merged into the qtwayland dev branch, but there is one more patch that is under review now.

Now I'm gonna talk about the recent development on Green Island.

Refactoring

Green Island now has:
  • a library that people can use to make their compositors reusing Green Island bits;
  • an executable named "greenisland" that links to the library and loads a separate QML based home screen;
  • an executable named "greenisland-launcher" that helps you run the compositor in several different environments;
  • a QML plugin that provides additional components such as the SurfaceRenderer for QML based home screens;

Launcher

Green Island can run on a number of different setups: X11, Wayland, Raspberry Pi, KMS, you name it.

There is now a launcher that detects where it is running, sets environment variables and runs the actual compositor accordingly.

Plugins

It's now possible to write custom home screens with QML.
The format is very simple but it might change slightly until the next iteration is released:
  • the home screen is a directory containing QML files and it's placed under $XDG_DATA_DIRS/greenisland (for example /usr/share/greenisland/org.vendor.coolhomescreen/)
  • the directory has a file called Compositor.qml and this is where you connect to the compositor and get events such as when a window is mapped or unmapped and create a QML window representation

xdg-shell

Green Island supports the old wl-shell protocol as well as the new xdg-shell protocol that is now required for weston and Gtk+ clients.

Qt clients can also use xdg-shell but it's not the default, users need to set an environment variable to enable it.

For both protocols Green Island has its implementation which is independent from the one that comes from QtCompositor.

This allows me more freedom and frees me from the qtwayland release cycle.

Announcing Qt World Summit 2015 Berlin

We are happy to announce that 2015 will give life to the Qt World Summit. It is the global event for all things Qt and a happening you won’t want to miss.

October 6-7 | bcc Berlin Congress Center, Germany

This past year, we have been uniting our ecosystem under www.qt.io making it easier to find all Qt-related information in one place for both our business and developer audiences. Our Downloads area and Documentation now reside under www.qt.io and next up are the Wikis and Forums also migrating to www.qt.io very soon.

Riding the coat tails of our ecosystem unification, we have entered a new era and we are transforming what has been Qt Developer Days to a refreshed and global event targeting both developers and business managers, Qt World Summit.


Going Beyond the Code

The Qt World Summit 2015 Berlin is a  two-day event where developers as well as business and product managers will be able to learn first-hand how Qt can support their entire technology strategy and quickly adapt to future application development and device creation trends. There will be dedicated business tracks where participants can learn how industry leaders have used Qt to create their future-proof products as well as get insight on how Qt can be used in their product technology strategy in industries such as automotive, consumer electronics and automation. The sessions will also present how companies can develop with Qt to create their own platforms, control their user experience and their business models. Attendees will get the chance to discover how simple it is to launch their own services on top of their independent platforms easily creating seamless integration between their services, devices and applications.


For Developers by Developers

Don’t worry. The developer love Qt Developer Days has had in the past 11 years is not going anywhere. If anything, it is going to be even more vibrant, more thriving. As this is the global event of the year, this is a great opportunity for all our developers to mingle with all Qt fans and lovers from all parts of the world. Qt unites us. For engineers and developers, the Qt World Summit will include an entire developer day where Qt development experts from The Qt Company and the ecosystem will present Qt’s latest features, functions and best practices, as well as several hands-on sessions. The developer day will also be dedicated to technical collaboration, lightning talks and tons of networking.


Get Warmed up with the North America Roadshow

To gets things started in 2015, this Spring we will host together with our Qt Services Partner, ICS, a North America Roadshow stopping for one day in the following locations: San Francisco (April 30), Houston (May 5) and Boston (May 7). The North America Roadshow is a one-day one-track conference with sessions on the Qt roadmap, Qt Quick, device creation and OpenGL, as well as lightning talks. More information to come soon. Stay tuned.


A Big “Thank You” to KDAB & ICS

For the past 3 years, our partners KDAB and ICS, have been responsible for the organization of Qt Developer Days Berlin and North America. Hats off to them for their amazing efforts and for putting on outstanding events keeping the ecosystem thriving. Thank you! We hope to continue to work with them and all our partners as we move along with the Qt World Summit.


Sign Up to Stay Informed

Please visit www.qtworldsummit.com to register your interest and stay informed. We will soon post information about  sponsorship opportunities, “Call for Papers”, agenda, registration opening and more.

We hope to see you in Berlin this year at the Qt World Summit!

Nicer debug output using QT_MESSAGE_PATTERN

If you are using Qt, you might have some qDebug or qWarning statements in your code. But did you know that you can greatly improve the output of those with the QT_MESSAGE_PATTERN environment variable? This blog post will give you some hints and examples of what you can do.

The default message pattern just prints the message (and the category if one was specified), but qDebug has the possibility to output more information. You can display cool things like the line of code, the function name or more by using some placeholders in the pattern.

QT_MESSAGE_PATTERN="%{message}"

Some example of placeholder:

  • %{file} and %{line} are the location of the qDebug statement (file and line number)
  • %{function} just shows the function name. Contrary to the Q_FUNC_INFO, which is really the raw function name, this shows a short prettier version of the function name without the arguments or not so useful decorators
  • %{time [format]} shows the time, at which the debug statement is emitted. Using the format you can show the time since the process startup, or an absolute time, with or without the date. Having the milliseconds in the debug output is helpful to get timing information about your code
  • %{threadid} , %{pid} , %{appname} are useful if the logs are mixed between severals application, or to find out from which thread something is run.
  • And you can find even more placeholders in the documentation.

Colorize it!

In order to make the output much prettier and easier to read, you can add some color by the mean of terminal escape sequences

Putting the escape sequence in an environment variable might be a bit tricky. The trick I use which work with bash or zsh, is to use echo -e in single back quotes.

export QT_MESSAGE_PATTERN="`echo -e "\033[34m%{function}\033[0m: %{message}"`"

That example will print the function in blue, and then the message in the normal color

Conditions

KDE's kDebug has colored debug output support since KDE 4.0 (it is enabled by setting the KDE_COLOR_DEBUG environment variable). It printed the function name in blue for normal debug messages, and in red for warnings or critical messages. I wanted the same in Qt, so some placeholders were added to have an output that depends on the type of message.

The content of what is between %{if-debug} and %{endif} will only be used for qDebug statements but not for qWarning. Similarly, we have %{if-warning} and %{if-critical}. There is also %{if-category} that will only be displayed if there is a category associated with this message.

Backtrace (linux-only)

On Linux, it is possible to show a short backtrace for every debug output.

Use the %{backtrace} placeholder, which can be configured to show more or less call frames.

In order for Qt to be able to determine the backtrace, it needs to find the symbol names from the symbol table. By default, this is only going to display exported functions within a library. But you can tell the linker to include this information for every function. So if you wish to use this feature, you need to link your code with the -rdynamic option.

Add this in your .pro file if you are using qmake:

QMAKE_LFLAGS += -rdynamic

Remember while reading this backtrace that symbols might be optimized away by the compiler. That is the case for inline functions, or functions with the tail-call optimization
See man backtrace .

Examples of patterns

And now, here are a few ready to use patterns that you can put in your /etc/profile, ~/.bashrc, ~/.zshrc or wherever you store your shell configuration.

KDE4 style:
export QT_MESSAGE_PATTERN="`echo -e "%{appname}(%{pid})/(%{category}) \033\[31m%{if-debug}\033\[34m%{endif}%{function}\033\[0m: %{message}"`"

Time in green; blue Function name for debug; red 3-frames backtrace for warnings. Category in yellow in present:
export QT_MESSAGE_PATTERN="`echo -e "\033[32m%{time h:mm:ss.zzz}%{if-category}\033[32m %{category}:%{endif} %{if-debug}\033[34m%{function}%{endif}%{if-warning}\033[31m%{backtrace depth=3}%{endif}%{if-critical}\033[31m%{backtrace depth=3}%{endif}%{if-fatal}\033[31m%{backtrace depth=3}%{endif}\033[0m %{message}"`"

Note that since Qt 5.4, the information about the function name of the file location is only available if your code is compiled in debug mode or if you define QT_MESSAGELOGCONTEXT in your compiler flags. For this reason %{backtrace depth=1} might be more accurate than %{function}

Don't hesitate to post your own favorite pattern in the comments.

Final words

The logging system has become quite powerful in Qt5. You can have categories and hooks. I invite you to read the documentation for more information about the debugging option that are at your disposal while using Qt.

Qt3D 2.0 The FrameGraph

Continuing our blog post series about the rewrite of Qt3D.

Introduction

For quite some time now, you’ve been hearing about Qt3D’s Framegraph. Although a brief definition of what the Framegraph is was given in the previous articles, this blog post will cover it in more detail. After reading this post, you will understand the difference between the Scenegraph and the Framegraph and see their respective uses. The more adventurous amongst you, will be able to pick up a pre-release version of Qt3D and start experimenting to see what the Framegraph can do for you.

Quite similarly to how the Scenegraph defines a scene out of a tree of Entities and Components, the Framegraph is also a tree structure but one used for a different purpose. Let’s explain what that purpose is and our motivation for this design.

Over the course of rendering a single frame, a 3D renderer will likely change state many times. The number and nature of these state changes depends upon not only which materials (shaders, mesh geometry, textures and uniform variables), but also upon which high level rendering scheme you are using. For example, using a traditional simple forward rendering scheme is very different to using a deferred rendering approach. Other features such as reflections, shadows, multiple viewports, early z-fill passes all change which states a renderer needs to set over the course of a frame.

As a comparison, the renderer responsible for drawing Qt Quick 2 scenes is hard-wired in C++ to do things like batching of primitives, rendering opaque items followed by rendering of transparent items. In the case of Qt Quick 2 that is perfectly fine as that covers all of the requirements. As you can see from some of the examples listed above, such a hard-wired renderer is not likely to be flexible enough for generic 3D scenes given the multitude of rendering methods available. To make matters worse, more rendering methods are being researched all of the time. We therefore needed an approach that is both flexible and extensible whilst being simple to use and maintain. Enter the Framegraph!

Each node in the Framegraph defines a part of the configuration the renderer will use to render the scene. The position of a node in the Framegraph tree determines when and where the subtree rooted at that node will be the active configuration in the rendering pipeline. As we will see later in this article, the renderer traverses this tree in order to build up the state needed for your rendering algorithm at each point in the frame.

Obviously if you just want to render a simple cube onscreen you may think this is overkill. However, as soon as you want to start doing slightly more complex scenes this comes in handy.  We will show this by presenting a few examples and the resulting Framegraphs.

Please note that unlike the Scenegraph which is composed of Entities and Components, the Framegraph is only composed of nested nodes which are all subclasses of Qt3D::QFrameGraphNode. This is because the Framegraph nodes are not simulated objects in our virtual world, but rather supporting information.

We will soon see how to construct our first simple Framegraph but before that we will be introduce the Framegraph nodes available to you. Also as with the Scenegraph tree, the QML and C++ APIs are a 1 to 1 match so you can favor the one you like best. For the sake of readability and conciseness, the QML API was chosen for this article.

FrameGraph Nodes

FrameGraph nodes specify how the renderer should sort rendering commands

FrameGraph Node Description
ClearBuffer Specify which OpenGL buffers should be cleared
CameraSelector Specifies which camera should be used to perform the rendering
LayerFilter Specifies which entities to renderer by filtering all Entity that have a matching Layer Components
Viewport Defines a rectangular viewport where the scene will be drawn
TechniqueFilter Defines the annotations (criteria) to be used to select the best matching Technique in a Material
RenderPassFilter Defines the annotiations (criteria) to be used to select the best matching RenderPass in a Technique
RenderTargetSelector Specifies which RenderTarget (FBO + Attachment) should be used for rendering
SortMethod Specifies how the renderer should sort rendering commands

 

The beauty of the Framegraph is that combining these simple node types, it is possible to configure the renderer to suit your specific needs without touching any hairy, low-level C/C++ rendering code at all.

Qt3D will provide default Framegraph trees that correspond to common use cases, however if you need a renderer configuration that is out of the ordinary, you will most likely have to get your hands dirty and write your own Framegraph tree.

FrameGraph rules

In order to construct a correctly functioning Framegraph tree, you should know a few rules about how it is traversed and how to feed it to the Qt3D renderer.

Setting the Framegraph

The FrameGraph tree should be assigned to the activeFrameGraph property of a QFrameGraph component itself being a component of the root entity in the Qt3D scene. This is what makes it the active Framegraph for the renderer. Of course, since this is a QML property binding, the active Framegraph (or parts of it) can be changed on the fly at runtime. For example, if you want to use different rendering approaches for indoor vs outdoor scenes or to enable/disable some special effect.

Entity {
    id: sceneRoot
    components: FrameGraph {
         activeFrameGraph: ... // FrameGraph tree
    }
}

Note: activeFrameGraph is the default property of the FrameGraph component in QML

Entity {
    id: sceneRoot
    components: FrameGraph {
         ... // FrameGraph tree
    }
}

How the Framegraph is used

  1. The Qt3D renderer performs a depth first traversal of the Framegraph tree. Note that, because the traversal is depth first, the order in which you define nodes is important.
  2. When the renderer reaches a leaf node of the Framegraph, it collects together all of the stat specified by the path from the leaf node to the root node. This defines the state used to render a section of the frame. If you are interested in the internals of Qt3D, this collection of state is called a RenderView.
  3. Given the configuration contained in a RenderView, the renderer collects together all of the Entities in the Scenegraph to be rendered, and from them builds a set of RenderCommands and associates them with the RenderView.
  4. The combination of RenderView and set of RenderCommands is passed over for submission to OpenGL.
  5. When this is repeated for each leaf note in the Framegraph, the frame is complete and the renderer calls our old friend, swapBuffers(), to display the frame.

If all of this sounds very complex, don’t worry, it is fairly complex but the good news is that using the Framegraph is really quite easy. At its heart, the Framegraph is a data-driven method for configuring the Qt3D renderer. Due to its data-driven nature, we can change configuration at runtime, allow non-C++ developers or designers to change the structure of a frame, and try out new rendering approaches without having to write 3000 lines of boiler plate code.

Let’s try to explain this more with the help of some examples of increasing complexity.

Let’s practice

Now that you know the rules to abide by when writing a Framegraph tree, we will go over a few examples and break them down.

A simple forward Renderer

Forward rendering is when you use OpenGL in its traditional manner and render directly to the backbuffer one object at a time shading each one as we go. This is opposed to deferred rendering (see below) where we render to an intermediate G-buffer. Here is a simple FrameGraph that can be used for forward rendering:

Viewport {
     rect: Qt.rect(0.0, 0.0, 1.0, 1.0)
     property alias camera: cameraSelector.camera

     ClearBuffer {
          buffers: ClearBuffer.ColorDepthBuffer

          CameraSelector {
               id: cameraSelector
          }
     }
}

As you can see, this tree has a single leaf and is composed of 3 nodes in total as shown in the following diagram.

simple-framegraph

Using the rules defined above, this framegraph tree yields a single RenderView with the following configuration:

  1. Leaf Node -> RenderView
    1. Viewport that fills the entire screen (uses normalized coordinates to make it easy to support nested viewports)
    2. Color and Depth buffers are set to be cleared
    3. Camera specified in the exposed camera property

Several different FrameGraph trees can produce the same rendering result. As long as the state collected from leaf to root is the same the result will also be the same. It’s best to put state that remains constant longest nearer to the root of the framegraph as this will result in fewer leaf nodes, and hence, RenderViews, overall.

Viewport {
     rect: Qt.rect(0.0, 0.0, 1.0, 1.0)
     property alias camera: cameraSelector.camera

     CameraSelector {
          id: cameraSelector

          ClearBuffer {
               buffers: ClearBuffer.ColorDepthBuffer
          }
     }
}
CameraSelector {
      Viewport {
           rect: Qt.rect(0.0, 0.0, 1.0, 1.0)

           ClearBuffer {
                buffers: ClearBuffer.ColorDepthBuffer
           }
      }
}

A Multi Viewport FrameGraph

Let’s move on to a slightly more complex example that renders a Scenegraph from the point of view of 4 virtual cameras into the 4 quadrants of the window. This is a common configuration for 3D CAD/modelling tools or could be adjusted to help with rendering a rear-view mirror in a car racing game or a CCTV camera display.

multi viewport scene

Viewport {
     id: mainViewport
     rect: Qt.rect(0, 0, 1, 1)
     property alias Camera: cameraSelectorTopLeftViewport.camera
     property alias Camera: cameraSelectorTopRightViewport.camera
     property alias Camera: cameraSelectorBottomLeftViewport.camera
     property alias Camera: cameraSelectorBottomRightViewport.camera

     ClearBuffer {
          buffers: ClearBuffer.ColorDepthBuffer
     }

     Viewport {
          id: topLeftViewport
          rect: Qt.rect(0, 0, 0.5, 0.5)
          CameraSelector { id: cameraSelectorTopLeftViewport }
     }

     Viewport {
          id: topRightViewport
          rect: Qt.rect(0.5, 0, 0.5, 0.5)
          CameraSelector { id: cameraSelectorTopRightViewport }
     }

     Viewport {
          id: bottomLeftViewport
          rect: Qt.rect(0, 0.5, 0.5, 0.5)
          CameraSelector { id: cameraSelectorBottomLeftViewport }
     }

     Viewport {
          id: bottomRightViewport
          rect: Qt.rect(0.5, 0.5, 0.5, 0.5)
          CameraSelector { id: cameraSelectorBottomRightViewport }
     }
}

This tree is a bit more complex with 5 leaves. Following the same rules as before we construct 5 RenderView objects from the FrameGraph. The following diagrams show the construction for the first two RenderViews. The remaining RenderViews are very similar to the second diagram just with the other sub-trees

multiviewport-1

multiviewport-2

In full, the RenderViews created are:

  1. RenderView (1)
    1. Fullscreen viewport defined
    2. Color and Depth buffers are set to be cleared
  2. RenderView (2)
    1. Fullscreen viewport defined
    2. Sub viewport defined (rendering viewport will be scaled relative to its parent)
    3. CameraSelector specified
  3. RenderView (3)
    1. Fullscreen viewport defined
    2. Sub viewport defined (rendering viewport will be scaled relative to its parent)
    3. CameraSelector specified
  4. RenderView (4)
    1. Fullscreen viewport defined
    2. Sub viewport defined (rendering viewport will be scaled relative to its parent)
    3. CameraSelector specified
  5. RenderView (5)
    1. Fullscreen viewport defined
    2. Sub viewport defined (rendering viewport will be scaled relative to its parent)
    3. CameraSelector specified

However, in this case the order is important. If the ClearBuffer node were to be the last instead of the first, this would results in a black screen for the simple reason that everything would be cleared right after having been so carefully rendered. For a similar reason, it couldn’t be used as the root of the FrameGraph as that would result in a call to clear the whole screen for each of our viewports.

Although the declaration order of the FrameGraph is important, Qt3D is able to process each RenderView in parallel as each RenderView is independent of the others for the purposes of generating a set of RenderCommands to be submitted whilst the RenderView’s state is in effect.

Qt3D uses a task-based approach to parallelism which naturally scales up with the number of available cores. This is shown in the following diagram for the previous example.

framegraph-parallel-build

The RenderCommands for the RenderViews can be generated in parallel across many cores, and as long as we take care to submit the RenderViews in the correct order on the dedicated OpenGL submission thread, the resulting scene will be rendered correctly.

Deferred Renderer

When it comes to rendering, deferred rendering is a whole different beast in terms of renderer configuration compared to forward rendering. Instead of drawing each mesh and applying a shader effect to colorize it, deferred rendering adopts a two render pass method.

First all the meshes in the scene are drawn using the same shader that will output, usually for each fragment, at least four values:

  • normal vector
  • color
  • depth
  • position

Each of these values will be stored in a texture. The normal, color, depth and position textures form what is called the G-Buffer. Nothing is drawn onscreen during the first pass, but rather drawn into the G-Buffer ready for later use.

Once all the meshes have been drawn, the G-Buffer is filled with all the meshes that can currently be seen by the camera. The second render pass is then used to render the scene to the back buffer with the final color shading by reading the normal, color and position values from the G-buffr textures, and outputting a color onto a full screen quad.

The advantage of that technique is that the heavy computing power required for complex effects is only used during the second pass only on the elements that are actually being seen by the camera. The first pass doesn’t cost much processing power as every mesh is being drawn with a simple shader. Deferred rendering, therefore, decouples shading and lighting from the number of objects in a scene and instead couples it to the resolution of the screen (and G-Buffer). This is a technique that has been used in many games in the recent years and although it has some issues (handling transparency, high GPU memory bandwidth and requires multiple render targets), it remains a popular choice.

Viewport {
     rect: Qt.rect(0.0, 0.0, 1.0, 1.0)

     property alias gBuffer: gBufferTargetSelector.target
     property alias camera: sceneCameraSelector.camera

     LayerFilter {
          layers: "scene"

          RenderTargetSelector {
                id: gBufferTargetSelector

                ClearBuffer {
                     buffers: ClearBuffer.ColorDepthBuffer

                     RenderPassFilter {
                           id: geometryPass
                           includes: Annotation { name: "pass"; value: "geometry" }

                           CameraSelector {
                                 id: sceneCameraSelector
                           }
                     }
                }
          }
     }

     LayerFilter {
          layers: "screenQuad"

          ClearBuffer {
               buffers: ClearBuffer.ColorDepthBuffer

               RenderPassFilter {
                     id: finalPass
                     includes: Annotation { name: "pass"; value: "final" }
               }
         }
     }
}

Graphically, the resulting Framegraph looks like

deferred-framegraph

And the resulting RenderViews are:

  1. RenderView (1)
    1. defines a viewport that fills the whole screen
    2. select all Entities that have a Layer component matching “scene”
    3. Set the gBuffer as the active render target
    4. clear the color and depth on the currently bound render target (the gBuffer)
    5. select only Entities in the scene that have a Material and Technique matching the annotations in the RenderPassFilter
    6. specify which camera should be used
  2. RenderView (2)
    1. defines a viewport that fills the whole screen
    2. select all Entities that have a Layer component matching “screenQuad”
    3. clear the color and depth buffers on the currently bound framebuffer (the screen)
    4. select only Entities in the scene that have a Material and Technique matching the annotations in the RenderPassFilter

Other benefits of the Framegraph

Since the FrameGraph tree is entirely data-driven and can be modified dynamically at runtime, you can:

  • Have different Framegraph trees for different platforms and hardware and select the most appropriate at runtime
  • Easily add and enable visual debugging in a scene
  • Use different FrameGraph trees depending on the nature of what you need to render for a particular region of the scene
  • Also by providing a powerful tool such as FrameGraph, anyone is able to implement a new rendering technique without having to modify Qt3D’s internals.

Conclusion

In this post, we have introduced the FrameGraph and the node types that compose it. We then went on to discuss a few examples to illustrate the Framegraph building rules and how the Qt3D engine uses the Framegraph behind the scenes. By now you should have a pretty good overview of the FrameGraph and how it can be used (perhaps to add an early z-fill pass to a forward renderer). Also you should always keep in mind that the FrameGraph is a tool for you to use so that you are not tied down to the provided renderer and materials that Qt3D provides out of the box.

As always, please do not hesitate to ask questions.

About KDAB

KDAB is a consulting company dedicated to Qt and offering a wide variety of services and providing training courses in:

KDAB believes that it is critical for our business to invest into Qt3D and Qt, in general, to keep pushing the technology forward and to ensure it remains competitive. Unlike The Qt Company, we are solely focused on consultancy and training and do not sell licenses.

The post Qt3D 2.0 The FrameGraph appeared first on KDAB.

Copying files over the network in a Qt application

Last week I visited a new customer who is making medical and industrial devices which have one thing in common: image and video capturing, and letting the user save these files onto a USB key. These devices run embedded Linux and the application is done in Qt (and gstreamer for the video capture). The new requirement, and the reason I was called in, is to be able to save these files over the network, to a samba or a webdav share. An abstraction framework for copying files over the network to multiple protocols is something I know very well: the KDE framework called KIO implements exactly that, and I happen to be its maintainer. And after the last 4 years of effort in making this much more modular, it is now possible to use KIO with very few dependencies, as we found out. In this two days on-site visit, I first explained many things about KIO (the API, the framework implementation, the available protocols, etc.), and then we started integrating it into their custom embedded linux distribution.

The KIO framework consists of 3 libraries (KIOCore, KIOWidgets, KIOFileWidgets) and a number of helper programs (daemons). However for this use case, only KIOCore is needed. Some user interface is needed: error and progress notification, the handling of “file already exists, overwrite/rename/skip?”, a dialog for entering user/password for the remote share, a way to display SSL certificate details and approval/refusal… But of course for all this, the KDE user interface (implemented by KIOWidgets) isn’t desired, rather another implementation that integrates better with the existing embedded GUI. The good thing is that the proper core/gui separation in KIO allows for exactly this: using only KIOCore and implementing some C++ interfaces to provide a customized user interface.

After adding an option to the KIO buildsystem for building only KIOCore, we were able to reduce greatly the number of required dependencies. Only the following are needed: extra-cmake-module (buildsystem), KCoreAddons (Job API), KConfig (configuration framework), KDBusAddons (daemon modules), KI18n (translation framework) and KArchive (for compressed HTTP transfers).

kio2

A simple patch commenting out some unneeded protocols for this particular use case allowed us to avoid some additional dependencies (e.g. Solid, for the “trash” implementation).

The dependencies listed above are all “tier 1″ frameworks, i.e. they only depend on Qt. So we were able to quickly integrate them into the hand-made linux distribution, and we have KIOCore ready to use. After copying over the unittests and setting up a few paths, we had all the tests running without errors.

The final hurdle was the process that handles SSL certificate policies, which was implemented as a module for KDED, a generic process that lives in another framework, bringing in more dependencies. I instead made it standalone, which solved the immediate problem. I’m now working on a better solution – a KIO daemon with multiple modules, for the various service that the KIO framework needs in a separate process (cookie handling, etc.)

On the topic of multiple processes, the customer appreciated greatly the fact that KIO protocol implementations (called “kioslaves”) are running in a separate process, because this allows them to look into running them as a different user, to give them limited permissions for security reasons. That user can have a read only access to the saved files (and to nothing else), since the use case is only upload operations.

All this in order to reduce the number of dependencies that KIO has, making it easier than ever to use KIO in any Qt application, so as to benefit from easy to use, asynchronous, well-tested network transparency with more than 90 different protocols available. I’m sure there are other applications with the same need :-)

The post Copying files over the network in a Qt application appeared first on KDAB.

Qt Weekly #26: Protecting your application against hacking

Open-source applications are open by nature, indented and encouraged for tweaking, hacking and further development. For a business critical application or a device there sometimes is desire to make it closed and prevent modifications. Because of the dual licensing, Qt offers a commercial license option that is well suited for making closed applications and devices allowing many ways of protection. Everything can be hacked, but it is possible to make hacking your Qt based application or device difficult.

For the purposes of this blog post, I have divided the ways to protect your application into three categories: legal means, securing the application and external protection. I concentrate into a few easily achievable and simple ways to make reverse engineering of a Qt based application difficult, not into making a binary fully secure or protected against tampering or copying. If the system needs to be fully secure, it has to be achieved by different means that making reverse engineering harder.

Legal means

Whereas the applications and devices using the open-source licensed Qt should be open for hacking and playing around, it is possible to prevent such when using a commercial license of Qt. One of the most important legal protection means provided by the commercial license of Qt is to forbid modifications and reverse engineering – and using various methods to prevent these. It is quite typical that the end user license agreement of an application or device states that reverse engineering is forbidden, which is allowed for commercial license. However for an application or a device created with the open-source licensed Qt it is not allowed to prevent reverse engineering or modifications, neither in the end user license agreement nor by making it difficult. In addition to legal protection the commercial license of Qt makes it possible to use various technical means to secure your application or device.

Securing the application

As it is allowed to legally prevent modifications and reverse engineering when a commercial license of Qt is used, it is also possible to take actions to prevent these. Static linking is one of the easiest ways of protection as it prevents changing the Qt binary used by the application and also makes reverse engineering harder. With static linking the application and Qt libraries are combined into the same binary. A possible hacker needs to take much more demanding and time consuming ways to modify the behaviour of the system compared to dynamically linked application.

When using static linking a good further measure to protect against reverse engineering is to strip symbol names away from the binary. Depending upon the compiler you use this is either automatically done for release builds, or can be done as an extra step for the statically linked binary. For example, MSVC automatically removes symbol names from a statically linked Windows release binary. On Linux and Mac this can be done with strip command. After the symbol table is removed from the statically linked binary, it is quite well protected against reverse engineering. These steps are easily done and do not require modifying your Qt application source code, thus static linking and removing the symbols can be regarded as the most efficient way to obfuscate the binary and to make reverse engineering difficult.

If use of dynamic linking is needed, some protection against simply changing the dynamically linked Qt library to a new version can be gained via using libinfix to change the library names (e.g. change libQt5Core to stgElse). Another approach is to change the used namespace with configure option –qtnamespace. Namespacing Qt puts all classes inside a defined namespace resulting, for example, QString being called someNewName::QString. In addition to using libinfix and namespaces it is also possible to use a generic c++ obfuscator for Qt applications. The protection gained by using all these means to a dynamically linked library is typically weaker than using static linking. When considering the level of obfuscation, it should be noted that no matter how much the code is obfuscated, it is still eventually possible to reverse engineer.

For Qt Quick applications it is recommended to use Qt Quick Compiler if there is desire to protect the QML parts of the application. While the application logic, and thus typically the most critical parts to protect, is usually done with c++ and therefore always compiled to binary, it is a good further measure to also protect the QML parts of the application. The Qt Quick Compiler compiles QML to binary and protects against reading the QML parts of the application. An additional benefit of the Qt Quick Compiler is improved performance of the application, especially at startup.

External protection

As the Qt application is just like any other binary running in your target operating system and hardware, you can use all generic means available for protection in your environment. Operating system may offer means to digitally sign the applications, as is typically the case with the applications distributed via application stores. There are also many different products available to provide security for application binary, and these typically work for Qt applications as well.

For embedded devices some protection is gained even without any special security hardware, as it is often difficult to get access to and modify software embedded into a physical device. The most efficient protection is to have hardware containing functionality to prevent a modified binary from running (either in the device hardware, or an external one, such as a USB dongle). In some cases it is also possible to leverage another system via a network connection to provide tamper protection. Static linking and obfuscating the binary make reverse engineering difficult, but only the external protection mechanisms of the target hardware and operating system provide full protection.

It should be noted that leveraging external protection typically requires a commercial Qt license, similarly as the other means of preventing user from changing or modifying Qt libraries. LGPLv2.1 is a bit ambiguous when it comes to whether or not the user should be allowed to run the modified application, but it is rather clear that it was the intention. For LGPLv3 it is clearly stated in the license that in addition to being allowed to modify the open-source library the user must be able to run the modified library as part of the system, and that the needed tools to achieve this must to be provided.

Summary

If there is a need to create a closed application or a device, the commercial license of Qt is the right choice. With the commercial license it is possible to utilize various means for making it difficult to modify functionality of the application or device built with Qt:

  • Making reverse engineering forbidden in end user license agreement and taking actions to prevent it is allowed when Qt is used with a commercial license.
  • An easy way to protect against modifications and reverse engineering is to use static linking instead of dynamic linking and build Qt into same binary with your application to prevent changing the Qt libraries.
  • When using static linking it is important to use release builds and when needed to manually strip out the symbols before distributing the binary.
  • If dynamic linking is needed, some protection against reverse engineering can be gained by building Qt with different names for libraries using libinfix and changing the used namespace. This mainly protects against user being easily able to change the dynamically linked Qt libraries – the protection against reverse engineering provided by static linking is much better.
  • Using Qt Quick Compiler that compiles QML to binary and protects against reading the Qt Quick parts of the application is an efficient way of further protecting your application.
  • No need to provide possibility to modify software embedded into a device, thus making it possible to use capabilities of the hardware and the operating system to prevent modifications to system software.

In case you want to learn more about the ways to protect your application, feel free to contact us. We can help you to implement protection for your application both via technical and licensing means.

Scalable UIs, Scaling the Content

text4180So far we talked about the technical aspects of scaling your application, the dpi, the number of pixels, its nature, the nature of image formats and the implications of all that on the creation of visual elements for your UI.

But this is only a part of the problem, for although all this helps you to create answers to your scaling problems, it does not answer the problems that created the need for those answers: the fundamental part of the problem.

As we very well know, “Only when you know the question, will you know what the answer means”.  Luckily in this case the question is easy enough and it is: “How do I scale my application across many devices?” So we only have to answer it. Unfortunately, however, 42 does not work well enough in this case and the sad reality is that there is no single definitive answer.

Nonetheless, there are some “rules” or general concepts, that if taken into consideration when finding the answer, do improve the quality of it. These rules will be subject of this blogpost.

 

 

DESIGN once, evaluate every time.

path3831

So after we get to scale our elements in a meaningful correct way, as we discussed in the previous posts, one could think that it would be enough to just set some base position rules and be done with it. Truth is that changes in screen ratio when porting your application to a new device don’t always go hand in hand with resolution changes and require a repositioning of components rather than simple scaling of the said components.

This means that sometimes we have and should use a different ratio to reposition our assets. A clear example is portrait and landscape form factors. Portrait traditionally comes better with single column layout, where in landscape we can have multiple columns.

As we also talked about in earlier posts, the fundamental metric for objects in this space is the size of the user’s finger, so when a screen gets physically larger we get more space for more fingers, ergo we might want to use that in our app providing more explicit functionality in each screen.

 

Platform matters.

rect4146

Porting your application to a specific platform does not occur in a vacuum. Most of the time each specific platform has extensive guidelines on how to tackle this, so even when we think we have a better answer, we have to understand that being right when everyone else is wrong is one of the worst experiences in this area. So try to comply with the user’s expectation in a specific platform.

 

 

It’s the principles that are meaningful not the pixels.rect3992

Your brand and experience concepts should stay regardless of screen/platform. This sentence is perpendicular to the previous point, and points out that as your application becomes available in multiple places you should not reinvent it at every turn. You should stay true with some predefined core image/interaction/experience principles that help define your brand and your application uniqueness across multiple points of interaction. You may need help – realise that this feels like and often resembles a perpetual exercise of “squaring the circle”. This space is evolving rapidly and the answers perpetually change, so seek help externally if you feel lost.

 

 

Start by not trying to make it perfect for all cases.

rect4461

Android, iOS, Windows Phone, BB10, Tizen, Windows Desktops, Linux Desktops, OSX, embedded etc. – there are several hundreds of different screens out there. Group them into areas, don’t try to make it perfect for every case in every platform. Start by discovering the target group of your application and choose a widely adopted resolution and platform as your start point. Define some simple base rules for scaling the application on the chosen platform, expand on the core principles developed there as needed. And then scale into other platforms.

 

 

Test, Test and then Test again.

Development and testing of your application on the Desktop ≠ the Device. This is vastly different in terms of experience and the final result. Test as much as possible – some things only make sense in the real thing.

 

 

The context is part of it.

Each platform is used in a different context and user mindset. A phone is used with the user on a specific position, location and attitude towards the iteration than for example a desktop. An embedded device can be used in extremely specific situations for example in an industrial plant. Use this info to evaluate how to scale each feature of your application on the canvas. Weight the content creation vs content consumption or the decision pattern in each case so that in each context the user might find what he is looking for. Users look for different things in different contexts.

 

 

 

In the end, Scaling is only one part.

image4013

Scaling your app correctly and efficiently is only part of the story. In fact the quality of the referred scaling is in great measure the result of a previously well-crafted User Experience, well defined User Scope, efficient Branding and good Usability.

 

 

This Concludes the series on Scalable Uis. I hope you found here information that might be useful for your work. It is not by any means an exhaustive view on the subject nor a definitive answer. What I hope with this series is to make some of the issues a bit more present, so that you might avoid costly loops of unplanned revision and bitter surprises, and gain a bit more understanding about the several aspects of scaling multiple concepts. I might revisit this topic if some new aspect surfaces that is interesting to talk about and relevant enough.

So see you soon.

The post Scalable UIs, Scaling the Content appeared first on KDAB.

Some Lesser Known Qt Tools and Commands - Part 1

Every Qt developer should be familiar with the common tools like qmake, Qt Designer and Assistant, but looking in your Qt installation's bin directory will reveal a few more programs there. In this and future blogs, we'll look at some of the lesser known Qt development tools.

Keyword Highlighting Support

One of the interesting new features in the upcoming Swift 3.0 release is support for “keyword highlighting”. This allows users to setup Swift such that it’ll alert them to activity that matches their configured highlighting rules. This is particularly useful where a user wants to be alerted when particular discussion topics, or keywords, are mentioned in chatrooms (highlighting rules are configured independently for private chats and chatrooms) - e.g. a Swift developer might choose to have a highlight configured to alert them when the word “Swift” is mentioned in a chatroom they watch, or a military operator may be interested in keywords such as “MEDEVAC”. Highlights can either be configured to be visual (with foreground/background colour applicable per rule), or may be audible (either with the default sound, or user-provided sounds per-rule). Here a keyword highlight for “Swift” rendered with black text on a green background is shown, along with a blue-on-red highlight for “late”.

Highlighting 'swift' and 'late'

As well as per-keyword highlighting rules, messages from a particular user may be subject to highlighting, e.g. the following screenshot shows a highlight configured for the Queen of Hearts’s user (black on yellow).

Highlighting the Queen of Hearts

These features will be released with Swift 3.0, and can currently be configured by selecting “Edit Highlight Rules” from the general menu in Swift.

(This post describes a currently unreleased feature, so details may change slightly before release)

What Makes Medical Device Software Design and Development Different?

Software development in general follows a particular flow. This article describes the software development process for medical device products and some of the notable differences within. Some examples of medical device products include everything from user interface design for image guided surgical tools, intraoperative devices, CT/MRI (as shown in Figure 1) and fluoroscopy imaging systems, surgical robotics and devices for tumor ablation.

Qt Weekly #25: Optimization hints on Qt Data Visualization

On Qt Data Visualization 1.1 we introduced a beta level optimization hint QAbstract3DGraph::OptimizationStatic and on 1.2 release the feature is fully supported. On this blog we’ll try to explore this optimization a bit more. We have also been asked how many items you can render on scatter graph. We hope that this blog answers to that question also.

So there are two optimization hints available for the scatter graph; OptimizationDefault and OptimizationStatic. Basically the difference on these hints is that the OptimizationDefault renders each item separately and the OptimizationStatic creates a rendering buffer and uses a single OpenGL call to render the buffer. The advantage on the OptimizationDefault is that it starts the rendering immediately and there’s no latency on getting the graph visible. The drawback on the other hand is numerous OpenGL calls which decrease the performance with large data sets.

The OptimizationStatic uses very few OpenGL calls and renders large data sets quite well. The drawback on this case is that the buffers have to be created before the rendering can start. The biggest factor for the buffer size and for the latency is the amount of vertices on the mesh type. For instance the smooth sphere has 264 vertices compared to cube’s 24 vertices, whereas the point has only one vertice. So once the buffer is created it is up to GPU’s power to process vertices. The best advice for large data sets is to aim to simple mesh types.

Let’s tackle the question about the biggest item count. From the Qt Data Visualization point there’s no hard limit for the item count. The ultimate limit comes from your graphics hardware when it just exhausts with the vertices. The question is now how many items you can have and still smoothly rotate and inspect the graph from different angles. Generally the excellent performance rate is considered as 60 FPS, but we can safely say that the usability remains good till 30 FPS.  To find out the limits we set up an application that gradually increased the number of items and measured the performance using QAbstract3DGraph::measureFps property.

The test was run on three different device ranging from embedded device to state of the art desktop PC. For the embedded device we utilized Boot to Qt stack from Qt for Device Creation running on Nexus 7 (device specs: Quad-core 1.2 GHz Cortex-A9 with ULP GeForce). As a laptop we used Lenovo T540p (Intel Core i7-4700MQ CPU 2.40GHz with Intel HD Graphics 4600) using Windows 7. For the desktop PC we chose Asus ROG TYTAN G30AB (Intel Core i7-4770K CPU 3.5GHz with NVIDIA GeForce GTX 780) using Windows 8.1. On the Nexus 7 we used full screen mode and on the PCs 1280 x 1024 pixels area.

Below is presented results of the test. On Boot to Qt powered Nexus 7 you can have around 1600 items with default optimization and still keep the performance on 30 FPS. Meanwhile with the static optimization there can be around 300 thousands of items. On standard desktop with default optimization you can have 18 000 items and still do fine and on static you can go up to 1.8 million of items. With rather powerful GPUs like NVIDIA GeForce GTX 780 using default optimization there can be around to 120 000 items and using static optimization we are talking about 24 millions of items.

results4

Conclusion

The default optimization is ideal if you want to have complex mesh types instantly on the display or you are constantly updating the data. For instance like on the rotations example, where the position and rotation of the arrows are constantly updated. If you have large static data sets, you get a good performance with static optimization. Simpler mesh types like the cube and pyramid performs reasonable well and don’t cause a noticeably latency. If you want to have custom mesh types, keep the number of vertices low, around 10-20 vertices. A point type is of course ideal for extremely large data sets. For instance to simulate a galaxy like presented on the example below where we have 105 000 star and dust items and the laptop is doing easily 60 FPS with static optimization.

galaxy2

Qt Creator flat style UI design + new Light theme

We have been thinking about the idea of updating the Qt Creator GUI with a more contemporary flat style design, and adding a Light theme in addition to the current Default and Dark themes. Moreover, all the icons in the UI would be simplified and become consistently unified under the same style.

Down below are a couple of screenshots with examples of what these new designs would look like. They are an early concept, so it we’d love to get useful feedback from you to take this forward!

And here are a couple of PDF documents with further examples of the new designs:

Qt Creator Flat style Default theme – PDF
Qt Creator Flat style Light theme – PDF

 

Default theme

QtCreatorThemes_DesignA_DefaultA1

Design mode

QtCreatorThemes_Edit_DefaultC1

Edit mode

 

Light theme

QtCreatorThemes_DesignA_LightA1

Design mode

QtCreatorThemes_Edit_LightC1

Edit mode

planet.qt.io is now live

Still one more service to hit the qt.io domain this week!

The Qt blog aggregator, Planet Qt, is now live at http://planet.qt.io

Planet gathers all the news and blogs from the Qt world to a single location. Anyone can submit their blog to be included into the planet feeds.

The current aggregator at http://planet.qt-project.org will stay open for several days, so you have time to change your links to point to the new address. We’ll be setting redirects on early next week.

Licensing of new modules in Qt 5.5

With the release of Qt 5.4, we added LGPLv3 as a licensing option to Qt. Some of the new modules released in Qt 5.4 (Qt WebEngine, Qt Canvas3D and Qt WebView) where made available under GPLv2+, LGPLv3 and commercial licensing terms. The reason was that we believe that this license combination is a better match than LGPLv2.1 for our objective of supporting Free Software while at the same time making sure we have the necessary funding to develop Qt further in the years to come. For more details, please check out the blog post from last summer.

Qt 5.5 is now coming closer, and we expect to have the Alpha release for it ready in February. While the focus of Qt 5.5 has been mainly on improving stability and fixing bugs, there will also be a couple of new modules added with the release. As with Qt 5.4, some of this new functionality is available under a LGPLv3/GPLv2+ and commercial licenses.

After discussing and agreeing with the main contributors of the modules in question, the KDE Free Qt Foundation and some of our main stakeholders, we consider this the best way to move forward. The new modules will be available under LGPLv3/GPLv2+ and commercial licensing terms. This allows us to make these modules available to the Free Software community, as well as being able to support and further develop them in the long term. The two new modules that will get added to Qt 5.5 under the new licensing terms are Qt 3D and Qt Location.

Qt 3D existed as part of the Qt Mobility APIs that Nokia did on top of Qt 4.8. Over the last two years, developers from our partner KDAB have put a lot of effort into refactoring the code base and making the API more flexible and suitable for the future. The API is now a powerful tool to integrate 3D content into Qt, featuring both C++ and QML APIs. Check out the series of blog posts from KDAB for more details about the APIs. KDAB endorses and supports to license this module under GPLv2+ and LGPLv3 for the open source version of Qt.

Qt Location is also a module that was part of the Qt Mobility APIs for Qt 4.8. As with Qt 3D it underwent lots of changes moving from Qt 4.8 to Qt 5, and is now also ready to become part of Qt 5. The API works in conjunction with the existing Qt Positioning module providing APIs for mapping, place search and navigation. It also comes with both C++ and QML interfaces.

The Qt Quick Enterprise Controls have so far been only available to commercial licensees. They offer a lot of really useful functionality on top of the regular Controls. With Qt 5.5, The Qt Company is going to contribute these to the open source Qt Quick Controls under LGPLv3/GPLv2+. This will affect the licensing of the Qt Quick Controls, and they will also now be available under LGPLv3, GPLv2+ and commercial terms. In addition to making the existing Enterprise Controls available to the Free Software community, we will also add a couple of new features. Amongst them is a fully functional TreeView, probably one the largest missing feature in Qt Quick Controls for the desktop platforms.

As we move along with releases, we expect to continue to license functionality under LGPLv3/GPLv2+ and commercial terms. It allows The Qt Company to grow its investments into new functionality in Qt and make it available to the Free Software community.

Meet with froglogic at Embedded World 2015

Hi,

froglogic will again be present at the Embedded World Conference in Nuremberg from February 24th – February 26th, 2015.

You will find froglogic at Halle 4 / Booth 4-301 and in the partner section at The Qt Company’s booth (Halle 4 / Booth 4-308) showing live demos of testing embedded HMIs with the Squish GUI Tester.

In addition, Reginald Stadlbauer from froglogic will give a talk at the Embedded World Congress with the title Automated testing of Qt and QML applications / Applying Behavior Driven Development and Testing.

If you would like to schedule a meeting at the Embedded World with a representative of froglogic, please contact us.

To meet us at Embedded World you can register for a free day ticket with the code B300759. For more information, see www.embedded-world.de/en.

The Qt blog is moving to the qt.io domain

We are approaching the move of one more service coming under the qt.io umbrella. This blog is about to move to it’s new home at http://blog.qt.io

The move is a continuation of unifying the Qt ecosystem under the qt.io domain.

We aim to make the move as transparent as possible. However we do need to turn off the comments for a couple of days to make a clean migration. Otherwise there should be no visible impact to you as a reader.

Akregator icon

Akregator icon

Once the move is done, the current address will be set to redirect to http://blog.qt.io
Please be prepared to update your rss-reader list at that time!

After the blog the qt-project.org wiki is next on the list of services to move. A separate post discussing the implications of that move will come along, once this blog has settled to it’s new home.

The Trolls invite you to Oslo

QtCS_2015The Qt Contributors’ Summit 2015 now has a date, the weekend of 6-7th June 2015.

The event is aimed at people who contribute to Qt in any way; code, documentation, bug reports, support on the forums, wiki editing, articles on the web, Youtube videos. In short anyone who contributes to the Qt community is welcome.

This year the location will be The Qt Company offices in Oslo. The location offers a relaxed atmosphere for discussions with even a possibility to hack something together if needed, while still having good room for even large groups for presenting on different parts of the project.

As always the Qt Contributors’ Summit is the premier event to discuss the state and the future of Qt with the maintainers, approvers and contributors of the project. For those interested in the project, it is a must event.

The format of the event will follow the unconference style that has been successfully used in previous years. A wiki page will be set up where you can add your topic proposals prior to the event, and as the event draws closer the exact schedule will be crafted based on the proposals.

Showing app

QtCS 2014

The event will begin on Friday with an unofficial get-together / hack event at The Qt Company offices.

And as we will be in Oslo, we hope to see many old trolls attend the event.

The event is based on invitations, please register for an invite.

If you are into Qt, Oslo in June is the place to be.

P.S. if you are interested in sponsoring the event, please contact tero.kojo@theqtcompany.com to discuss the matter further.