We’ve officially gone into String Freeze mode now! That’s developer speak for “No New Features, Honest”. Everything that’s going into Krita 4.0 now is in, and the only thing left to do is fixing bugs and refining stuff.

Given how much has changed between Krita 3 and Krita 4, that’s an important part of the job! Let us here repeat a very serious warning.

THE FILE FORMAT FOR VECTOR LAYERS HAS CHANGED. IF YOU SAVE AN IMAGE WITH KRITA 4.0 THAT HAS VECTOR LAYERS, KRITA 3 CANNOT OPEN IT. IF YOU OPEN A KRITA 3 FILE WITH VECTOR LAYERS IN KRITA 4, THE VECTOR LAYERS MIGHT GET MESSED UP. BEFORE WORKING ON SUCH FILES IN KRITA 4, MAKE A BACKUP.

This doubles for files that contain text. Text in krita 3 is based on the ODT standard, text in Krita 4 is implemented using SVG. This beta is the first release that contains the new text tool. Here’s the low-down on the new text tool:

• It’s not the text tool we wanted to create, and you could consider it as a stop-gap measure. Because of all the tax office worries, we simply didn’t have the time to create the fully-capable opentype-integrated text tool that we wanted to do.
• But we couldn’t keep the old text tools either: they were broken, and based on ODT. We needed to have something that could replace those tools and that would would be functional enough for the simplest of use-cases, like text balloons in a comic.
• So, what we’ve got is simple. There’s no vertical text for Chinese or Japanese yet, there’s no OpenType tweaking, there’s no fine typographic control.
• The user interface is not final yet, and there are quite a few things that need polishing and fixing, and that we’re working on, but Krita 4’s text tool will be mostly what we’ve got now.

Apart from that…

This beta contains pretty much everything… We started working on some of these features, like the export feedback in 2016. Here’s a short list:

• SVG vector system, with improved tools and workflow
• New text tool
• Python scripting
• SVG import/export
• Improved palette docker
• Bigger brush sizes
• Improved brush editor
• Refactored saving and exporting: saving happens in the background, and export shows warnings when your file contains features that cannot be saved to a given file format
• A fast colorize brush
• The default pixel brush is much faster on systems with many cores
• Lots of user interface polish

And there’s much more, but please download the builds, or build Krita and see for yourself!

One thing that is still in progress is updating the set of default brush presets: those aren’t in the beta yet, but they are in the nightly builds.

Platform Notes

Windows

• There is only a 64 bits build. We haven’t decided whether we want to provide 32 bits builds at all on Windows yet.
• There are now nightly Windows builds available as well.

Linux

• The AppImage does not contain support for audio in animations
• The AppImage does not have Python scripting
• The AppImage does include the latest gmic-qt release

OSX

• The app bundle does not contain gmic-qt
• The app bundle does not contain Python scripting
• The app bundle does not have support for importing PDF files

Download

Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.

• 64 bits Windows: krita-x64-4.0.0.51-setup.exe
• Portable 64 bits Windows: krita-x64-4.0.0.51.zip
• Debug symbols. (Unpack in the Krita installation folder)

Linux

• 64 bits Linux: krita-4.0.0-beta.1-x86_64.appimage

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

When it is updated, you can also use the Krita Lime PPA to install Krita 4.0 beta 1 on Ubuntu and derivatives.

OSX

• OSX disk image: krita-4.0.0-beta.1.dmg

Note: the gmic-qt and pdf plugins are not available on OSX.

Source code

• Source code: krita-4.0.0.51.1.tar.gz

md5sums

For all downloads:

• md5sum.txt

Key

The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
0x58b9596c722ea3bd.asc. The signatures are here.

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

This blog post will get you started with Qt 3D Studio remote deployment to Qt 3D Viewer on Android devices. This feature enables making changes to your Qt 3D Studio presentation on your computer and seeing the changes live on the target device.

Qt 3D Studio Editor & Viewer with the remote connection feature

Setting Up the Target Device

To set up the target device for remote deployment, follow the steps below.

1. Download Qt 3D Viewer from Google Play and install it on the target device.
2. Run the Viewer.
3. From the file menu, select File > Connect.
4. Enter desired port or use default port, press OK.
5. Connection information, IP address and port, will be displayed in the Viewer.

Connecting to the Target Device

To connect to the target device from Qt 3D Studio, follow the steps below.

1. From the file menu, select File > Connect to Device.
2. Enter the connection information displaying in the Viewer on the target device, then press OK.
3. You are now connected. The Viewer on the target device should display Remote Connected.

Preview Presentation

To preview the presentation on the target device, press the Preview button in the Studio toolbar. After making changes to your presentation, press the Preview button again to see the changes on the target device.

The Preview button in Studio

Disconnecting from the Target Device

You can disconnect from the target device either by selecting File > Connect to Device from the Studio file menu, or by selecting File > Connect from the Viewer file menu.

The post Qt 3D Studio Remote Deployment on Android Devices appeared first on Qt Blog.

If you are using Qt and you need to run some code in a separate thread, chances are that you are using QThread for the job. QThread is a very old class in Qt, making its first appearance in Qt 2.2, released on the 22nd of September 2000. Its responsibility is to start a new thread, and let you execute code in that thread.

There are two main ways of running code in a separate thread using QThread:

1. subclassing QThread and overriding run();
2. creating a "worker object" (some QObject subclass) and connecting it to QThread signals.

Please refer to my Qt World Summit 2017 presentation (video) for more details about how to use these two functions. There are also lots of other documentation and blog posts available on the internet, discussing the pros and the cons of the two approaches.

Enter QThread::create()

In Qt 5.10 I have added another way to run some code in a new thread. Inspired by C++11's std::thread, I have introduced QThread::create, a factory function that creates a new QThread which will run a user-provided callable:

[sourcecode lang="cpp"]
QThread *thread = QThread::create([]{ runSlowCode(); });
thread->start();
[/sourcecode]

The advantage of this approach is that it avoids creating a new QThread subclass manually for the sole purpose to override its run() member function and run some code.

Unlike std::thread, however, the newly-created thread is not automatically launched; the user is expected to start it with an explicit call to start(). This allows users to do some extra work before starting the thread, for instance, connect to its signals, set the name of the thread, or change its priority, as demonstrated by this snippet:

[sourcecode lang="cpp"]
QThread *thread = QThread::create(myFunction);

thread->setObjectName("WorkerThread"); // name to appear in ps, task manager, etc.
connect(thread, &QThread::started, gui, &Gui::threadHasStarted);

thread->start();
[/sourcecode]

The user acquires ownership of the newly-created QThread object.

With a C++17 capable compiler it is also possible to pass extra arguments to QThread::create(): these arguments will be then passed to the function in the new thread, using the same semantics as std::thread's constructor. For instance:

[sourcecode lang="cpp"]
QThread *thread = QThread::create(myFunction, arg1, arg2);
// extra setup...
thread->start(); // calls myFunction in another thread, passing arg1 and arg2
[/sourcecode]

That's it! I hope this will be useful to you. However, the API of QThread::create() is only half of the story. If you want to know more about what this apparently little patch meant for Qt, keep reading.

Implementation notes

In afterthought, the implementation of QThread::create is very simple. However, when doing the necessary research, I found a small oddity with the C++ Standard Library that deserves some attention.

The most important constraint I imposed on myself when writing QThread::create was to be as compatible as possible with std::thread's constructor semantics. If one reads the relevant section in the Standard (f.i. here), one can see that the actual semantics of the invocation are quite complex. The extra arguments to the function undergo a transformation (specified as DECAY_COPY), they're stored "somewhere", and finally the functor is invoked using the INVOKE function. Both DECAY_COPY and INVOKE are not actual Standard Library functions, but pseudo-functions formally defined elsewhere in the C++ Standard.

An oddity that I found during my research is that the C++11 Standard does not provide these building blocks to end-users (and by that I also include developers of other C++ libraries, like Qt). A way to use INVOKE for user code got added in C++17 with the std::invoke function; however, there is simply nothing ready-made that applies the DECAY_COPY transformation, and stores the callable and its decayed/copied arguments, and possibly even invokes the function with the right semantics.

The only workaround that I have found was to use a higher-level thread primitive provided by the Standard Library: std::async. std::async has the same invocation semantics as std::thread's constructor; it returns a std::future that we can use to examine the result.

We can force std::async to not spawn an additional thread and to run the callable only when asked to do so, by specifying the std::launch::deferred launch policy. std::launch::deferred allows a sort of lazy evaluation: the callable is invoked only when one tries to access the result (via the returned std::future object):

[sourcecode lang="cpp"]
auto future = std::async(std::launch::deferred, function, arg1, arg2);

// some time later, possibly in another thread:
future.get(); // calls the function with the arguments
[/sourcecode]

This is exactly how QThread::create() is implemented: it calls std::async on the user-provided function and its arguments, and stores the returned std::future in an instance of an internal QThread subclass. This subclass overrides run(), which in turn simply calls get() on the future (see here and here). This machinery isn't zero-overhead, as the combination of std::async and std::future does way more than what we need, but it at least shifts the burden of the implementation from Qt onto the Standard Library.

The extra plumbing needed is the aforementioned std::invoke, which however is only available in C++17. Under a C++17 compiler, QThread::create() takes a callable and its arguments, whereas under a pre-C++17 compiler, QThread::create() only supports a callable (and no further arguments). In practice this isn't a big limitation, because one can always use a lambda to wrap the callable and its arguments, and then pass the lambda as the only argument.

Qt and the Standard Library ABI

The addition of QThread::create() to Qt was also possible because of a major policy change in Qt.

A little bit of history: up to and including version 4, Qt did not require the presence of a Standard Library implementation on the system (the configure script had a -no-stl option). From version 5.0 Qt started to require a working Standard Library implementation: the configure switch was dropped, and Qt code dealing with Standard Library types was compiled unconditionally. Qt itself started using Standard Library types (notably, containers) in its own implementation, mostly where such types provided more features or performance when compared to Qt's own versions.

However, Qt has never exposed Standard Library types from its public ABI: all functions taking or returning Standard Library types had to be inline (example). The main reason for doing so was to make the same build of Qt compatible across different Standard Library implementations (e.g. libc++ and stdlibc++, or two ABI-incompatible builds of the same implementation).

After lots of debate, this has finally changed in Qt 5.10: Qt is now allowed to expose Standard Library types from its public ABI. Users wishing to mix-and-match Standard Library implementations need to recompile Qt. (In other words, we've made this Someone Else's Problem).

What does this have to do with QThread::create()? As I explained before, the current implementation uses std::async under the hood. The std::future returned by std::async is then passed to an exported, out-of-line Qt function, which constructs and returns the result -- the QThread instance that runs the user-supplied function. (The reason for doing such a thing is because QThread is an exported polymorphic class. A subclass defined entirely inline would generate copies of its vtable / type_info in all the translation units using it, and this may cause problems.) Therefore, now std::future is part of Qt's own ABI; and I'm very glad I didn't have to re-implement it! continue reading

The post New in Qt 5.10: QThread::create appeared first on KDAB.

Could you tell us something about yourself?

I’m a 30-year-old housewife and mother living in New Mexico in the United States. I’ve always had an interest in becoming a storyteller, and visual art is the most appealing way for me to do it.

Do you paint professionally, as a hobby artist, or both?

Right now I would call myself a hobbyist, as I’ve never published anything professionally. I hope for that to change. What I need is to somehow find the time and energy to crank out images at high volume!

What genre(s) do you work in?

I’ve always been interested primarily in fantasy, although much of my work has consisted of humorous cartoons. Humor creeps into whatever I try to make whether or not I intend for it to be there. My goal for the next decade is to begin a serial, consistent fantasy world as portrayed through cartoons.

Whose work inspires you most — who are your role models as an artist?

My first and largest influences are the old-fashioned Disney animated films from the 20th century, as exemplified by the work of artists like Bill Tytla. I also consider cartoonists and illustrators like Bill Watterson, Maurice Sendak, and Hal Foster to be very influential on my style. Fantasy illustrators like Frank Frazetta inspire me on an emotional level.

How and when did you get to try digital painting for the first time?

I began using digital tools purely as a form of practice a few years ago. To me it was very casual; I was figure drawing and making fan art referencing in-jokes from a favorite podcast of mine called “We Hate Movies.” I didn’t intend to pursue it seriously, but found myself returning to it more and more often.

What makes you choose digital over traditional painting?

Traditional painting definitely produces the most beautiful results, but it’s a pain in the neck. Not only does it take up more time and physical space, it’s far more expensive and wasteful. I don’t like the “digital look,” and it will take a lot of practice to minimize that. However, I believe that real artists should never blame their tools for any failure.

I’d almost always drawn pictures with only a pencil before, but digital painting allows me to ink and color my images much more easily. It also opens up options for experimentation when I can simply recolor anything I don’t like. The hardest part has been trying to learn the kind of control with a stylus that I have with my own hand.

How did you find out about Krita?

My husband is an engineer who works frequently with Linux and is familiar with the open-source world. He suggested Krita to me when I was looking for a digital painting program not called Photoshop.

What was your first impression?

Krita was the most professional-looking Photoshop alternative that I’d come across. It also played nicely with my stylus and tablet in a way that some other software didn’t. Krita did have some bugginess and crashing, though.

What do you love about Krita?

That it’s free! I think it’s remarkable that the open-source community could create something of this quality without a money spigot. Given Adobe’s outrageous pricing scheme for Photoshop, you’d think that software like this couldn’t exist anywhere else. Krita is a much better option.

What do you think needs improvement in Krita? Is there anything that really annoys you?

Bugs and crashes come with the territory in open-source projects, but those are likely to be reduced over time. The real problem is how inaccessible Krita is to lay people. When I was looking to download the program for the first time, I had to follow a completely unintuitive chain of links that, to somebody like me, appeared to be made up of Seussian nonsense words (AppImages for cats? What’s a Gentoo? Why is it bloody?). Idiots like myself just want a giant button that says “GET THE LATEST STABLE VERSION OF KRITA HERE!” The way things are now, the less technically literate will give up on trying Krita before they have even started.

What sets Krita apart from the other tools that you use?

Krita has a great community of support that will ensure that it gets better year by year. It has the right priorities, i.e. essential tools like layers and brushes get implemented before more obscure features. Other than occasional crashes, I can just jump in and use it.

If you had to pick one favourite of all your work done in Krita so far, what would it be, and why?

I made this page in Krita in order to see whether I could use it for a webcomic I plan on creating. The experiment was a success, and I believe that my skills will continue to grow. This proves that I can use Krita to tell the kinds of stories that I have plans for.

What techniques and brushes did you use in it?

I mostly use a basic round brush that I resize accordingly. Line brushes are convenient for separating the panels. I think that skills are more important than tools, and I want to train myself to use the simplest tools that I can.

Where can people see more of your work?

I’m shy about publishing, but I realize that this is something I need to change about myself. Once I’ve worked up a sizable volume of content, which should be within the next year, I will be posting a regular webcomic called The Unknown Engine.

Anything else you’d like to share?

I’m grateful that the Internet and the open-source movement affords artists like me the opportunity to create and publish in new ways. I often think about Bill Watterson’s long fight with his syndicates, and how different it would have been for him if he was able to publish Calvin and Hobbes on the Internet under his own control. I’m nowhere near his level of course, but I want to improve my own skills until I get there.

The 5th and final bugfix update (5.11.5) of the Plasma 5.11 series is now available for users of Kubuntu Artful Aardvark 17.10 to install via our Backports PPA.

This update also includes an upgrade of KDE Frameworks to version 5.41.

To update, add the following repository to your software sources list:

ppa:kubuntu-ppa/backports

or if it is already added, the updates should become available via your preferred update method.

The PPA can be added manually in the Konsole terminal with the command:

sudo add-apt-repository ppa:kubuntu-ppa/backports

and packages then updated with

sudo apt update
sudo apt full-upgrade

Upgrade notes:

~ The Kubuntu backports PPA includes various other backported applications, so please be aware that enabling the backports PPA for the first time and doing a full upgrade will result in a substantial amount of upgraded packages in addition to Plasma 5.11.5.

~ The PPA may also continue to receive updates to Plasma when they become available, and further updated applications where practical.

~ While we believe that these packages represent a beneficial and stable update, please bear in mind that they have not been tested as comprehensively as those in the main Ubuntu archive, and are supported only on a limited and informal basis. Should any issues occur, please provide feedback on our mailing list [1], IRC [2], and/or file a bug against our PPA packages [3].

1. Kubuntu-devel mailing list: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
2. Kubuntu IRC channels: #kubuntu & #kubuntu-devel on irc.freenode.net
3. Kubuntu PPA bugs: https://bugs.launchpad.net/kubuntu-ppa

We are happy and proud to announce the immediate availability of Zanshin 0.5.0.

After 0.4.0 one year and a half ago and 0.4.1 last year (which wasn't publicly announced), this new release introduce new features. The 0.4 series was mostly about the Qt 5 port and stabilization, now we can be a bit more ambitious again.

So what's in store for that new release?

• Errors coming from the system are now displayed properly in the main window;
• Tasks scheduled in the future can be filtered out;
• A task can be picked up as the "currently running" showing a nice overlay at the top of the screen, this is a reminder of what you're supposed to focus on;
• Projects are now displayed grouped by their containing collection which can help separate better visually between work and personal projects;
• Attachments are now supported for tasks (which nicely complete the "create todo" feature from KMail);
• Tasks with recurrence are now supported (although we have a simple recurrence model for now);
• And of course also a couple of minor GUI adjustments and bug fixes.

Under the hood, we also did some improvements:

• Some error handling has been improved;
• Some duplicated code has been factorized;
• Some dead code has been cleaned up;
• Issues pointed out by krazy and clazy have been addressed;
• Feature level tests have been reworked and are better insulated from each other;
• Our code related to dates have been ported to the new KCalCore ABI introduced in 17.12;
• The biggest architectural change has been the introduction of a cache which speeds up our accesses to akonadi and allowed to adress a few bugs (we had some views exhibiting duplicated items, this is now gone).

So quite a lot of nice things in this release. We increased the features and polish of what you experience while improving the code base itself. All in all, this should be a very nice release.

As usual, you can grab 0.5.0 while it is fresh! Packages for KDE Neon and openSUSE Tumbleweed are already available, it's only a matter of time until the other distributions catch up.

Plasma 5.11.5 KDE Neon

https://www.kde.org/announcements/plasma-5.11.5.php

Now available in KDE Neon User Edition!

Challenges with cloud messaging for embedded devices has inspired the Kaltiot & SnowGrains teams to create a cross-platform Qt API which enables easy push messaging from and to embedded devices. The API is called the Qt Cloud Messaging API and it is built with flexibility and extensibility in mind.

We have decided to target other Qt areas, too, and make the API easily extensible to any service provider instead of being for embedded only. This enables developers to use the same API for both mobile and desktop development.

There is a vast number of push messaging providers for mobile and web development nowadays. Yet in industries like automation, automotive, robotics and for other embedded devices there has not really been any providers for this type of service. The need is increasing at a rapid pace as embedded and IoT devices are pushed more and more messages by the device owners, car service providers, telemetry, cloud and many others.

The Qt Cloud Messaging API is simple to adopt and take into use.

Let’s take a sneak peek at how to utilize the API for embedded systems and Android mobile platforms. We’ve integrated the Kaltiot Smart IoT SDK and the Firebase C++ SDK into the backend, and with the Qt Cloud Messaging API we can easily create e.g. a chat application on top of it.

Kaltiot Smart IoT is a service for scalable and secure messaging between devices and services. It provides bi-directional and always online, yet battery optimized communication. The client SDK is designed to work even in constrained low-end devices in poor wireless network conditions. Kaltiot Smart IOT is available for Linux32, Linux64, Raspberry Pi, Mac, Android.

How to use the Qt Cloud Messaging API for embedded devices:

 First, clone the qtcloudmessaging repository: git clone https://codereview.qt-project.org/qt/qtcloudmessaging

Service provider

Pre-requirements:

1. Get the Kaltiot SDK to your embedded device from (e.g. Linux or Raspberry Pi SDK) https://console.torqhub.io
2. Get the API key for sending channels or/and creating server-side implementation
3. Add following line to your application .pro file: QT += cloudmessagingembeddedkaltiot
4. Define KALTIOT_SDK path to your application.pro
5. Add following includes to main.cpp

#include <QtCloudMessaging>
#include <QtCloudMessagingEmbeddedKaltiot>

6. Add following QtCloudMessaging configs to main.cpp

// Instantiate CloudMessaging library
QCloudMessaging *pushServices = new QCloudMessaging();

// Add provider for Kaltiot Embedded systems
QCloudMessagingEmbeddedKaltiotProvider *kaltiotPushService = new QCloudMessagingEmbeddedKaltiotProvider()

// Provider based init parameters are given with QVariantMap
QVariantMap provider_params;

provider_params["API_KEY"] = "Your API key from the Kaltiot console for server communication";
// Creating name for provider which can be used cross your app.

pushServices->registerProvider("KaltiotService", kaltiotPushService, provider_params);

QVariantMap client_params;

client_params["address"] = "IOTSensor1";
client_params["version"] = "1.0";
client_params["customer_id"] = "Kaltiot";

// Creating default channels to listen
QVariantList channels;
channels.append("weather_broadcast_channel");
client_params["channels"] = channels;

// Connect IoT sensor client to system
pushServices->connectClient("KaltiotService", "IOTSensor1", client_params);

//! Automatically subcribe to listen one more channel e.g. WindInfo.
pushServices->subsribeToChannel("WindInfo", " KaltiotService ", " IOTSensor1");

1. Provide context of cloud messaging to QML in main.cpp

//! Provide context to QML

engine.rootContext()->setContextProperty(“pushServices”, pushServices);

QML Part:

in main.qml catch the messages coming from the Kaltiot service.

1. Receiving messages

Connections{
target : pushServices
onMessageReceived:{

//! Message is received as string and needs parsing to JSON
console.log(message)
}
}

2. Sending messages:

//! Sending a broadcast message e.g. from the weather station:
//! Message structure for embedded devices is easy:
//! define payload json:
//! {
//!   “payload_type”:”STRING”,
//!   “payload”: encodeURI(JSON.stringify(payload))
//! }
//! Payload is your application specific. E.g:
var payload =
{
msgType:”NEW_WEATHER_INFO”,
city: “Oulu”,
forecast: “full sunlight for whole next week”
}

//! Capsulate payload to message and send it via QtCloudMessaging API:
var payload_array = [{“payload_type”:”STRING”,”payload”: encodeURI(JSON.stringify(payload))}]

pushServices.sendMessage(JSON.stringify(data), ”KaltiotService”, ”IOTSensor1”, ””, ”weather_broadcast_channel”);

Using the Qt Cloud Messaging API for Android / iOS mobile development with Google Firebase service provider

Pre-requirements:

1. Create new project into Google Firebase console: https://firebase.google.com/
2. Download Google Firebase C++ SDK  and add the Firebase configuration file for Android Gradle:

DISTFILES += \android/google-services.json

3. Add following line to your application .pro file:

QT += cloudmessagingfirebase

Define Google firebase path into your application.pro file with

GOOGLE_FIREBASE_SDK = <Path_to_Firebase_SDK>

4. Add following includes to your main.cpp

#include <QtCloudMessaging>
#include <QtCloudMessagingFirebase>

5. Add following QtCloudMessaging setup to main.cpp:

// Instantiate CloudMessaging library
QCloudMessaging *pushServices = new QCloudMessaging();
QCloudMessagingFirebaseProvider *firebaseService = new QCloudMessagingFirebaseProvider();
QVariantMap provider_params;

// Server API key is not recommended to store inside to the application code due security reasons.
// But if you do, make sure it is inside compiled C file or if you are doing a server side implementation with C++ & Qt.
// SERVER_API_KEY Is needed to be able to send topic messages from the client without Firebase application server.

provider_params["SERVER_API_KEY"] = "Get your SERVER API KEY from the google firebase console";

// Registering the Google firebase service component.
pushServices->registerProvider("GoogleFireBase", firebaseService, provider_params);

/*! Connected client is needed for mobile device.
\param Service name "GoogleFireBase"
\param Client identifier name to be used inside the application
\param Parameters for the client. No params for firebase client.
*/
pushServices->connectClient("GoogleFireBase", "MobileClient", QVariantMap());

//! Automatically subscribe to listen one example topic
pushServices->subsribeToChannel("ChatRoom", "GoogleFireBase", "MobileClient");

1. Provide context of cloud messaging to QML in main.cpp

//! Provide context to QML
engine.rootContext()->setContextProperty(“pushServices”, pushServices);

QML Part:

in main.qml catch the messages coming from the google firebase

1. Receiving messages

Connections{
target : pushServices
onMessageReceived:{
//! Message is received as string and needs parsing to JSON
console.log(message)
}
}

2. Sending messages:

//! For firebase, message structure needs to have data as whole message.
//! Notifications are shown in the Android/iOS notification center.
function sendMessage(notification_titile, notification_msg, msg){
var data = { “data”:{
“message”: {“text”:msg } },
“notification” : {
“body” : notification_msg,
“title” : notification_titile
}
}

//! Give data and service provider identifier as well as client name defined in the C++ code.
pushServices.sendMessage(JSON.stringify(data),”GoogleFireBase”,”MobileClient”,””,”ChatRoom”);
}

You can play around with the Qt Cloud Messaging API + firebase from the sample

https://github.com/snowgrains/qtcloudmessaging-examples

The Qt Cloud Messaging API provides cross-platform API to enable us to include new providers and still keep the development API as same.

The Qt Cloud Messaging API has been developed to be easily extensible to any service provider. Take a sneak peek at ongoing development from the https://codereview.qt-project.org/qt/qtcloudmessaging and contribute your own backend service to the community.

Kaltiot has been developing and hosting IoT cloud services since 2008. Trusted e.g. by Microsoft, Kaltiot passes through 10M messages every hour. (www.kaltiot.com)

SnowGrains provides Full Stack Software Solutions On The Rocks.(www.snowgrains.com)

Ari Salmi is multi-technology developer and Qt enthusiast.

The post Qt Cloud Messaging API Available for Embedded Systems appeared first on Qt Blog.