Deprecation notice: bluez, gnutls, qtconnectivity, qtsysteminfo, repomd-pattern-builder

Announcements
#1

In the Sailfish OS 4.4.0 Vanha Rauma release notes we announced that a number of packages would be removed from future releases. One of these was QtWebKit, which we discuss in a separate post.

In addition, all of the following will be removed in the Sailfish OS 4.5 release:

1. bluez
2. gnutls
3. qt5-qtconnectivity-qtbluetooth
4. qt5-qtsysteminfo
5. repomd-pattern-builder

None of these packages have been allowed as dependencies for apps in harbour, so their removal won’t affects apps downloaded from there.

However, apps from other sources such as OpenRepos and Chum may fail as a result of these changes. From a users’ perspective, any apps that retain these dependencies will be automatically uninstalled at the next update.

We’d therefore urge any developers making use of these packages to update and release new versions of their apps.

Below are some extra notes about the packages themselves and potential alternatives. However, please feel free to reply with a comment if you run in to trouble with a particular app, and we’ll do our best to help.

bluez

The bluez package provides Bluez 4 Bluetooth support, which in practice has for some time only been used on older devices. The Xperia devices all use Bluez 5 and hence the newer bluez5 package. App developers should switch to using the Bluez 5 DBus interface or kf5bluezqt.

GnuTLS

All of the default installed components have been converted to use OpenSSL rather than GnuTLS, and we’d recommend app authors to follow a similar approach. Removing GnuTLS in favour of OpenSSL allows us to reduce our maintenance burden.

QtConnectivity

QtConnectivity has in the past been used as an interface for Bluez 4. However, with the bluez package being dropped it no longer makes sense to have the qt5-qtconnectivity-qtbluetooth package. App developers are again advised to switch to using the Bluez 5 DBus interface or kf5bluezqt.

qtsysteminfo

There are a number of alternative APIs for accessing system info, including ssu-sysinfo, ssu and nemo-qml-plugin-systemsettings. If access to system info is needed by your app, we suggest converting to use one of these alternatives instead.

repomd-pattern-builder

The repomd-pattern-builder tool provides a set of scripts for building patterns for the repository. We stopped using it some time ago — ever since the 3.4.0 release in fact — and we don’t believe it’s widely used. It’s unlikely to be of use for app developers.

12 Likes
[4.5.0.16] Kuri doesn't start
[Release notes] Sauna 4.6.0.11
Community meeting on IRC 23rd June 2022
#2

QtConnectivity

kép

Attracting the developers with a mobile platform without proper Bluetooth API in 2022?

#3

I’m not sure I understand (maybe there’s a misunderstanding). The bluez5 DBus API is supported, and available as part of the “Bluetooth” permission that’s allowed in Harbour.

Apologies if this wasn’t clear from my post.

3 Likes
#4

Okay. Let’s keep it simple. You have a random gadget which requires writing A and B value to a given characteristics.

Could you please highlight some documentation/example how to do it with the kf5bluezqt?

With QtBluetooth is quite straightforward. It has excellent documentation and examples which could be used as a starting point for most purposes.

I am not saying it’s bugfree, but for me dropping the support for that on SFOS is considered a huge backward step. Not to mention that it is still supported upstream as of today (Qt 6.3) which would keep the possibility of creating cross platform apps…

3 Likes
#5

I can appreciate that different developers will prefer different APIs, and it’s frustrating when the one you want to use isn’t supported. Personally, I’ve always found the bluez DBus API to be the most functional, but it may not be as straightforward as QtBluetooth. QtBluetooth has never been harbour-supported as far as I’m aware.

The following gives a very brief summary of how you might go about doing something like this using the DBus API.

List devices:

dbus-send --system --dest=org.bluez --print-reply / org.freedesktop.DBus.ObjectManager.GetManagedObjects

Connect to one of the devices listed:

QDBusInterface *device = new QDBusInterface("org.bluez", "/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX", "org.bluez.Device1", QDBusConnection::systemBus(), this);
QDBusPendingCall async = device->asyncCall("Connect");
...

Get the characteristic you want to write to:

QDBusInterface *characteristic = new QDBusInterface("org.bluez", "/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/serviceXXXX/charXXXX", "org.bluez.GattCharacteristic1", QDBusConnection::systemBus(), this);

Write “A” to the characteristic:

QVariantMap options;
QByteArray bytes("A");
QDBusPendingCall async = characteristic->asyncCall("WriteValue", bytes, options);
...

I’m not sure what your broader goals are, but if you think this looks like a way to achieve what you need and want to give it a go, or if anyone else would find it useful, I’d be happy to have a look for more documentation or a more complete example.

7 Likes
#6

Thanks @flypig. I have on my to-do list to make a SFOS app to connect to a Bluetooth power meter we have at our lab. So far we use a python script on Linux (which also works on SFOS in the terminal) or the manufacturer windows app.
I’ll give dbus bluez a try to see if it works with it, because, as you outline it here, this seems quite easy to implement.

1 Like
#7

I’d be happy to have a look for more documentation or a more complete example.

Well you win ;).

I think it would be definitely good to make some basic documentation about characteristics, device discovery, characteristics read/write/notifications.

2 Likes
#8

Agreed, this would be useful. I’ll see if I can find anything good that’s already out there and we can at least collect together some good links.

If you find anything good during your investigations @orangecat, please share!

1 Like
#9

I remember struggling with basic bluez5 dbus usage some time ago, and this was sadly among the best findings that actually helped me make some/any progress… Perhaps contributing directly to bluez5 documentation is also something to consider.

#10

Also, there is https://github.com/piggz/qble

1 Like
#11

I looked after the QtConnectivity and it looks like that the Bluez5 support was introduced in the Qt 5.4.0:
https://bugreports.qt.io/browse/QTBUG-32085

Are there any reason why the bluez5 based QtConnectivity could not remain?

1 Like
#12

Mainly because maintaining it consumes resources. I appreciate you’ve wanted it properly supported for some time, and it will still be possible for someone else to maintain their own versions of the libraries in the future.

However, converting apps to Bluez or kf5bluezqt would be better in my view.

To add to the general discussion, the best reference docs for Bluez 5 in my experience are those in the bluez source tree. They’re terse, and lack useful examples, but all of the info is there. I agree that @piggz’s qble repo linked is a really great resource too (I’ve referred to it many times in the past).

@martonmiklos: your BLE Scanner app covers a lot of functionality, so I had a go at switching it from QtConnectivity to Bluez. Maybe it’s useful for others who are looking at making the switch. I included references to the docs and equivalent dbus-send calls to help add context to the code.

#13

Mainly because maintaining it consumes resources.

What if we would do a PoC backporting and ship it without “warranty”? (Maybe through OBS.)

As mentioned before the BLE API was not allowed to the Harbour. Is there any care after ten years to have it in the Harbour?

Every (other) platform tries to offer the best in class API for all sort of things.
Are we sure that adding DBUS and Bluez as an API for Bluetooth is what could be called best API for interacting BLE devices?

I am not bitching for myself, I could live with the stuff mentioned above, but for the developers might come to the platform in the future…

What will we tell to somebody who want to interact BLE devices on SFOS?
Familiarise yourself with DBUS first and then with Bluez? It simply does not work out if you a newcomer.

your BLE Scanner app covers a lot of functionality

I would not call this my app, it is just a Qt Example wrapped into a Silica view.

I have an another BLE app for SFOS:

I almost started to port it to pure QML to being able to make it cross platform between SFOS/Android, but in this case this is not going to a valid task anymore.

1 Like
#14

That’s what I was meaning when I suggested someone could maintain their own version, for example via Chum (assuming it fulfils the requirements after it’s removed from the Jolla repositories, but that’s a matter for the Chum maintainers).

Use of the Bluez 5 BLE API is allowed in harbour. For example, those changes I proposed to the BLE Scanner app allow it to pass harbour validation.

This is a totally valid concern, and I agree entirely with you raising it. In addition, we all put a lot of effort into learning and becoming expert in a particular API; switching is no small undertaking.

Nevertheless, I would say that the advice you give there is good advice, especially for Sailfish OS which makes heavy use of DBus, not just for Bluetooth but throughout. I’m less familiar with kf5bluezqt, but maybe that’s a better alternative for someone not wanting to get into DBus.

QtBluetooth isn’t a perfect solution either. For example, unlike Bluez 5 it doesn’t support BLE advertisements.

Agreed, unfortunately writing a cross platform Sailfish and Android app becomes less viable without QtConnectivity.

2 Likes
#15

So I now took a stab at porting a QBluetooth application to kf5bluezqt. For the most part the API, especially the Qml part is really nice. But as soon as you need to go lower level, like open an rfcomm socket, you basically need to implement everything yourself. QBluetoothSocket is actually pretty nice for that, since it handles all the logic for you and you just need to give it the address. Reimplementing that is quite a pain.

1 Like
#16

It also seems like kf5bluezqt is outdated by around 4 years, so all of the characteristics stuff is missing.

#17

As qt5-qtsysteminfo will be removed I did some tests with nemo-qml-plugin-systemsettings as @flypig suggested here Sailfish Community News, 21st April, Sailfish SDK 3.9 - #10 by flypig.

I am under the impression that not all parameters in deviceInfo are set. I was looking for imei info (imeiNumbers, which looks undefined), but the same goes for something like wlanMacAddress.
The strange thing is that aboutSettings.wlanMacAddress works from systemsettings, but deviceInfo.wlanMacAddress is undefined at the same time.

deviceInfo.manufacturer is one of the values that is properly set btw.

What am I missing?

#18

Kudos for taking the plunge, and thank you also for sharing your experiences. I was also very happy to see the constructive question you’ve raised for the next community meeting. I’ve not used kf5bluezqt myself so it’s hard for me to give any good advice about it, but I’ll do my best to try to find someone who can.

1 Like
#19

I can only make a guess, but could it be that you’re not instantiating DeviceInfo? Using the following piece of code, the result wasn’t pretty, but it did show the correct IMEI numbers on my Xperia 10 II.

import QtQuick 2.0 
import Sailfish.Silica 1.0
import org.nemomobile.systemsettings 1.0

ApplicationWindow {
    property DeviceInfo deviceInfo: DeviceInfo {}
    initialPage: Component {
        Page {
            Label {
                text: "IMEI: " + deviceInfo.imeiNumbers
            }
        }
    }
}

I tried with imeiNumbers, wlanMacAddress and manufacturer and all gave correct values. If you share your code I’d be happy to explore it with you further.

#20

Used your piece of code, but the result is the same as in my testcase (using Xperia XA2 Plus Dual sim):

  • IMEI: undefined
  • WLAN MAC: undefined
  • Manufacturer: Sony

As mentioned earlier aboutSettings.wlanMacAddress does return a valid WLAN MAC for me.