It’s been a big week for Jolla and the Sailfish community. Phew, I’m exhausted just thinking about it.
On Monday we saw the roll out of Sailfish OS 126.96.36.199 to Early Access subscribers. This addressed several of the issues identified in the previous Early Access release, including a neat fix in the hardware adaptation layer to access the front camera for Android VoIP calls (crafted in collaboration with the Sony Open Devices team), a fix for a bug that prevented some documents from opening in the Office app, and mobile data issues when restarting Android App Support.
Then on the same day we saw the first ever release of Pure Maps in the Jolla Store. We’ll talk more about that shortly.
During the week it was decided the Early Access release was in good shape, which allowed the full release to happen on Thursday for all supported devices. We’re really pleased with the response. All of your very positive comments, suggestions and bug reports spur us on to drive Sailfish forwards.
The full release of Kvarken 4.1.0 also brought the paid components for the Xperia 10 II in all their full 64-bit glory. In practice this means the Android App Support and the Exchange ActiveSync support, which we know are essential capabilities for many users. Predictive text input for the Xperia 10 II remains one missing piece, but we’re still working hard to get it out to you. Given the big shift to 64-bit and the new device, the Jolla release team chose to roll out the updates in stages to minimise unexpected problems: first the non-paid version, followed by the full version. The approach seems to have been successful, and while there will always be some teething problems, overall we’re really happy with how things worked out.
If you’ve not already done so, I strongly recommend you have a read of Simonas’ excellent post on the Jolla Blog about the Kvarken release. It explains the main differences in full, the technical challenges of moving to 64-bit, and also some of the ways our amazing community (that’s you) helped to make it happen. It’s a great read.
On Friday David Greaves announced the important news, after much discussion both internally and with you in the community, that the community OBS will be refurbished and refloated. As David explains:
We’ve been listening to the community and we’re pleased to announce that the Community OBS will be kept in service for at least another 12 months… We are looking into updating the OBS to a newer version in the near future and hopefully this will fix the aarch64 support too.
Thanks to all of you who have been making use of the OBS service, and to those of you who offered help with the upgrade.
And in case that wasn’t enough, yesterday the Sailfish SDK 3.5 was released to Early Access subscribers. As vige explains in the release notes, the main changes are an updated Qt Creator and RPM package signing support. If you’re an Early Access user then you’ll receive a notification in the Sailfish IDE about the upgrade. If you’re not using the Early Access version then do check the release notes to find out what to expect when the full release goes live.
In parallel with all this, there’s also been a lot of lively discussion, including during the last community meeting, on the topic of Freenode and IRC. Jolla and the Sailfish community have been using IRC since the beginning (with the very first log entry — “Merbot has joined #sailfishos” — recorded back in 2013). In the last couple of weeks the Freenode service which the channels rely on has undergone some tumultuous changes. There’s been plenty written on the topic elsewhere, so I won’t dwell on the details. Suffice it to say it’s opened up the question of whether it’s time to move to a difference service, maybe even a different protocol. I can announce that nothing has been decided, and that discussion is ongoing. If you’d like to add your own voice to the discussion, I’d suggest joining us at the next Community Meeting on 3rd June where it will surely be discussed further, or contribute to the forum thread.
An eventful week. In amongst all this excitement it’s been great to see that you all continue to upgrade your apps to 64-bit, with growing numbers being added to the Jolla Store and OpenRepos. Watching the amazing effort of the community is, in fact, one of the greatest joys of putting together this newsletter, and so we wanted to dig a little deeper into some of the things you’ve been up to. We spoke to two community devs: Adam Pigg (piggz) and Rinigus, to talk about the development of their apps for Sailfish OS.
When the original Jolla 1 was released in 2013 it came with a native Maps app that utilized HERE mapping data. The app was never adopted by the Sailfish X programme, although HERE WeGo was available for some time in the Jolla Store. More recently a number of replacement mapping apps have been developed by the community, most notably Poor Maps, by Osmo Salomaa and modRana by Martin Kolman. Both of these relied on online mapping services to provide the mapping data. That is until Rinigus stepped in with OSM Scout Server in 2016, a locally hosted “mapping server” that granted both of those apps the ability to work offline. A couple of years later Poor Maps evolved into Pure Maps (via WhoGo Maps), by that time also maintained by Rinigus, resulting in what I’m going to call a “full stack” solution.
If you’re looking for mapping on your Sailfish OS device, then you should definitely give Pure Maps a try. It’s a great demonstration of what’s achievable with open source, and could give many commercial mapping apps a run for their money (don’t forget to choose the right hiking difficulty for the race!) If you want to know more about the capabilities of the app itself, jump to the “Energy from the Community” section below.
Pure Maps has always been available on OpenRepos, but due to the tight but important Harbour policies it’s never been possible to get it accepted into the Jolla Store. That is until now. Recent changes to Harbour policy have now made this possible. As Rinigus explains:
The main change allowing Pure Maps to join Jolla Store was introduced by Ville (vige) on 8 Jan 2021. This change in policy allowed to use QtPositioning 5.4 import in the applications submitted to the Store. Change became a part of SFOS 4.0.1 release in Feb 2021.
I started working on introducing changes in Pure Maps somewhat later, as I wanted to write TBuilder that allows me to build aarch64 apps in an automated manner - something that we are still not able to do at community OBS (although this is going to change soon!). Without such automated build systems, applications requiring many libraries, as a mapping stack does, are very time consuming to build. So, it took some time before I managed to start working on Pure Maps changes required by submission to the Store.
But it wasn’t just about policy. Rinigus also had to make some changes to the app itself.
On Pure Maps side, some political changes had to be introduced. I had to start importing QtPositining 5.4 and drop support for older SFOS versions. As SFOS is using the oldest Qt versions, it was a step in the right direction - although it is never pleasant to remove backwards compatibility.
Jolla Store requires all the supporting libraries to be packaged with the application if they are not ‘approved’. As a result, I had to bundle libqmapboxgl (Mapbox GL Native) and QML module that I developed for it earlier (Mapbox GL QML). To use the bundled module, C++ main had to be adjusted to load it from non-standard location. Interestingly, module loading failed when using SFOS boosters, so those had to be disabled for Jolla Store version leading to probably slower loading of the app.
Finally, the last change was to drop extra .desktop made for handling geo: URI.
With these changes Pure Maps was able to sail its way into Harbour (presumably using the “Ferries: Prefer” option). Having a first-rate Mapping solution in the Jolla Store is a great step forwards, and thanks go to Rinigus for all of his work on it. However, Rinigus also makes the point that the Jolla Store and OpenRepos versions are not identical.
In practice, we have now two builds - OpenRepos and Jolla Store. OpenRepos is using the shared Mapbox GL QML and has full functionality. Also, text-to-speech and offline maps still need OpenRepos apps. These differences have to be considered when you choose the version.
If like us you’re impressed by Rinigus’s work, or if you just want to support an excellent contributor to the open source Sailfish OS community, do consider donating to the project. And if Pure Maps isn’t to your taste, then you should also take a look at OSM Scout by Lukáš Karas (Karry), another excellent offline mapping app that’s also in the Jolla Store and OpenRepos.
A couple of newsletters back attah (of SeaPrint and Tint fame) took the trouble to suggest some excellent topics for future inclusion in the newsletter. We always appreciate suggestions and will always try to follow them up if we can. One of the ideas was to include Amazfish, which attah described as “Truly brilliant work.”. Well, how could we ignore an endorsement like that?
Amazfish is a companion app for a variety of different smartwatches, including the Amazfit line of smartwatches from Zepp Health Corporation (previously Huami), from which the app derives its name. Amazfish now supports a whole host of other smartwatches beyond the original Amazfish Bip, including the PineTime which has been generating a lot of interest in the open source community recently. If you own one of the supported watches you can control it via the app, often with comparable capabilities to the official apps from the watch vendors themselves.
If you want more info about the capabilities of Amazfish, check out our summary in the “Energy from the Community” section below. We thought it would be interesting to get an insight into Amazfish by way of its author, Adam Pigg. We threw some questions at him, and he very kindly took the time to reply with some great answers, which you can read in full below.
If you’re an Amazfish user and find the app useful, or if you just want to support another excellent contributor to the open source Sailfish OS community, do consider donating to the project.
Tell us a little about yourself.
I’m a husband and father of four, and enjoy programming and an out-doors life, walking and mountain biking. I work on Sailfish and my open source projects as a hobby. Regarding Sailfish, well, around 2010 I was a KDE/KOffice/Kexi dev. Someone from Nokia got me on the developer program and sent me an N900. After that it was the N950 and N9, but then Stephen Elop happened and that was that! Like some other Qt devs, I got on the Blackberry 10 program and wrote apps there for a while, but was always aware of Sailfish. I decided I like the idea of a Sailfish phone, but as I wasn’t used to spending a lot on phones, I bought an HTC ACE and started my first port!
Tell us about your role as a Qt Ambassador and a STEM Ambassador.
Well, I probably should update my profile, as the ambassador program was scrapped some time ago, but it was a program for people who are passionate about Qt programming. Being a STEM ambassador is about promoting Science, Maths, and in my case, Technology and Engineering to school students. I occasionally go into schools and run programming afternoons with python, Raspberry Pi’s etc.
What is Amazfish and what does it do?
Amazfish is a watch companion application for Sailfish (and now other distros) similar to Rockpool for the Pebble, but for a different set of devices. It’s intended to not be too tied to a particular device, but works best with the Amazfit devices like the Bip and GTS (which I own and use most) but also supports the PineTime and Bangle.JS. It supports notifications, calendar reminders, syncing steps and sports, sleep analysis and upload to Strava.
What made you decide to develop Amazfish?
My Pebble was starting to play up and look dated. The Bip looked reasonably priced as a replacement, but didn’t have a companion app. Not one to shy away from a challenge, I wondered how difficult it could be to reverse engineer and implement the BLE comms. I learned a lot about BLE and GATT, capturing the BLE traffic on android and analysing it in Wireshark. I also became aware of the GadgetBridge program for Android which has similar goals, and, useful to me, already implemented the Huami/Amazfit protocol in Java, which I could at least use as a reference.
Tell us about the watches Amazfish supports.
I would describe them as “smarter” watches. They don’t have user-installable apps other than watchfaces, so not as powerful as an Android, Apple or Samsung watch, but they also have great battery life, and just the right number of features for me (notifications, steps, and GPS tracking).
Pine64 became aware of Amazfish, and thought it was a good idea to send me a PineTime dev kit. That introduced me to embedded programming and I added some features to the PineTime firmware which could be used from Amazfish, such as notifications, music control, and a navigation application that works in conjunction with Pure Maps.
Which is your favourite watch?
My “daily driver” is the GTS (kindly supplied to me by the community!). It does everything I’d (currently) want from a watch. The PineTime is a lot of fun and fully open, so has a lot of potential, but doesn’t have GPS. The Bangle does have all the hardware, and is fully open, but the software is still work-in-progress, but could be a good contender as a daily device in the future.
What’s the Infinitime firmware for the PineTime like?
Well, I’m maybe a little biased on Infinitime as Ive made several features for that firmware! I think its a great project with an inclusive community and has a lot of potential. I think the software now pretty much fully supports all the hardware and just needs some missing features such as logging activity and a bit more polish.
How have you taken user privacy into account with Amazfish?
I don’t think anyone running a Linux/FOSS device would have any interest in uploading their health data to the likes of Apple or Google (I find it a little concerning you can now get health insurance benefits so long as you have an Apple Watch and share your data), so I thought the best way to empower someone to be in control of their data and to give them the most visibility of it, would be to make it accessible on a desktop application. From the start Amazfish was always going to need a database to store data, and as I was also a Kexi dev, it seems a natural choice to allow the user to open their own health data inside Kexi. This would allow a knowledgable user to add to the existing analysis that is in Amazfish with their own queries and reports if they wished. I’m not sure anyone takes advantage of that, but it seems like a reasonable goal to allow it!
That hasn’t come without a burden though, the Kexi libraries link against libicu which doesn’t provide a stable ABI, so needs to be recompiled for each Sailfish release. If I chose to stick to Qt only, and use a plain sqlite database, I would have a lot less packaging issues, and it would be easier to build Amazfish. Fortunately, I’ve been able to move a lot of that burden onto the community OBS system, which takes care of a lot of the building for me.
What other libraries do you use?
I use some of the calendar libraries, and dbus to intercept notifications and calls. These are wrapped up in a fork of libwatchfish, which is a library to help watch app devs by javispedro. Mapbox QML by Rinigus is used for displaying the GPS activities. I also wrote my own library to handle the BLE GATT communications because my first implementation using Qt didn’t work so well. The QBLE library wraps the bluez dbus GATT api and seems to work reasonably well for me.
What part of the app are you most proud of?
Kinda tough to say… from a technical level, QBLE and all the low level comms is interesting; there is the firmware update for the PineTime which runs in a separate thread too; all good low level details. But, I also know users get very irate when their step and sleep charts are wrong, so I guess I’m just glad that the app allows people to track their health and use it to improve their level of activeness.
You’ve structured the app source code in a very particular way.
I think you must be referring to the top level folders and sub projects. I guarantee that it didn’t start like that, and initially looked like a relatively simple Sailfish project. All the main folders are either useful for the user or for myself as a maintainer. Starting with the
lib/ folders the application used to just be a normal app, but no-one wants to have an app running to get incoming notifications, so it seemed sensible to split into a systemd service and a UI which communicate over DBus. The service can run in the background and handle comms to the watch so you don’t have to remember to load it up. That itself has caused issues, like users not starting the daemon and expecting it to ‘just work’, so I’ve changed that recently to always start the daemon when the UI starts, if it is not running.
Then there are the
libwatchfish/ submodules. At the start, neither of these existed. I had to create QBLE to work around issues with Qt’s BT handling, and thought it could be re-usable by other projects, so made it a stand-alone library that can be compiled into an application. Finally, libwatchfish was added when I wanted to add calendar notification support. Instead of just taking the code, I realised that it implemented other functionality I had previously written myself, such as music control and notifications, so the obvious solution from a maintenance perspective was to remove all my own code and use the library instead. This reduces the code maintained in the app, even if I now have another project to maintain. It at least adds a clear boundary between functions and cleans up the code in Amazfish.
What was hardest to develop?
I think the hardest was right at the start, wondering how do I talk to a BLE device, not knowing what a GATT Service or Characteristic were, and not knowing what bytes to send. Probably without GadgetBridge as a reference, a lot of this would have been impossible, or taken a lot longer. The devs there are wizards at looking through Wireshark logs!
For advice, I would always say start small. You can’t implement everything in version 0.1. My original goal was to talk to a single device, the Bip, with a single-threaded app. With evolution, that is now multiple devices, a DBus interface, service integration, etc.
How has the community helped?
I’ve had a number of important contributions: translations, build fixes for other distros, UI improvements and even time handling fixes (time is hard!).
At some point in the project I decided to abstract away the device implementation into the aptly name “AbstractDevice” class. The idea here was to make it easier for other interested devs to add support for other devices, however, I’ve yet to have someone make a PR for a new device!
How easy was it to integrate Strava into the app?
I think so long as the external API is HTTP and JSON/XML based, then there should be no problem implementing that on Sailfish.
How do you find writing code that works on multiple platforms?
Some people don’t find Sailfish to be free software, so these people want to use other distros such Manjaro and Mobian on the Pinephone or Librem. The Pinephone devs were obviously keen on the PineTime being available in as man places as possible, and it seemed reasonable to port my Sailfish-only app to other distros. This wasn’t easy, but was greatly simplified using Rinigus’s set of QML components, which wrap the platform components such as Silica and Kirigami.
It wasn’t easy, but i ported the whole UI to a new set of components, and had Amazfish running on my regular Linux desktop for free using Kirigami.
With a few more
#ifdefs in the daemon, everything was running, and I just needed to ask the distro packagers to do the final bit of work to get it running on their systems.
Generally, people on those distros are people I recognise from the wider community anyway, so working with them is really easy
What are your future plans for Amazfish?
Certainly support for more devices and improved support for some of the devices which just happen to work. I can’t have every watch, so more devs and a bigger community would make the project more sustainable. I can fix bugs on devices I don’t own to some extent, but its not as easy!
It might be nice to integrate support with other health monitoring devices. Perhaps some people need to monitor blood sugar for example.
What are your predictions for the wearables of the future?
I’d like to see the growth of Linux and FOSS devices, and for people to be in control of their own data. Though it will probably be some time before we can take on Apple, i think there is a small set of users which aren’t catered for with the latest Samsung or iPhone, so the likes of the Pinephone will hopefully bring FOSS devices to a wider audience at a low cost. We also have other companies like F(x)tec and Volla openly promoting and supporting Sailfish and Linux on their devices, so hopefully our sector will grow. It might be nice if Jolla would allow for Sailfish to be pre-installed on a wider set of devices, but this is one of the bigger legal situations I prefer to avoid!
What other apps do you use?
I think the most important apps on my phone are:
Thank you Adam for such a great insight into Amazfish and life as a Sailfish OS dev. I hope this gives some inspiration to anyone thinking of building their own app but who hasn’t started yet: start simple and things can grow from there. Apart from building apps, Adam is also a prolific porter, and last weekend he presented about his latest port to the Volla Phone at the Volla Developer Day. Check out the recording of the live stream to see how this work is progressing. Adam also kindly offered for any budding devs who want to get in touch to ping him on Twitter or as @adampigg on Telegram. And as is the beauty of open source, everyone is free to peruse the Amazfish source code on github.
As always, there were far too many apps updates or released this fortnight for us to cover them all, but here’s our curated selection.
In case you got this far without figuring it out already, Amazfish is a smartwatch companion app created and maintained by Adam Pigg (piggz). To properly make use of it you’ll need one of the supported hardware devices, which currently includes the Amazfit Bip, GTS, BipS, Cor, GTR and Bip Lite; the PineTime Infinitime; the Bangle.js; and the MiBand 2, 3 and 4. Not all of these have the same level of support, but for the “Gold” set of devices most of the functionality is covered: pairing, notifications, fitness monitoring and charting (steps, heart rate, etc.), watchfaces and firmware updates. There’s even support for the Strava service, including visual route maps to show exactly how far and where you’ve been travelling. Amazfish has a loyal userbase and it’s a very accomplished smartwatch companion app. If you already have one of the supported watches then you should certainly give it a go. If you’re thinking about getting a smartwatch or fitness tracker, then you should at least consider looking at the supported devices to see whether they fit your needs. The latest version performs automatic service startup, and also gets the codebase ready for a 64-bit release. There are however currently no aarch64 or Sailfish OS 4.1.0 compatible versions available, but Adam expects them to both be ready just as soon as OBS supports those targets, and possibly sooner. This latest version is available from OpenRepos.
Pure Maps is undoubtedly a brilliant piece of software, one of the best open source mapping apps, not just in Sailfish OS, but arguably across the open source mobile landscape. Is this overstating it? Well, if I’m honest we didn’t check all the other mapping apps, but it’s certainly up there. The current version is Written and maintained by Rinigus (building on and including work from other contributors too), Pure Maps is an online and offline map, route planning and navigation app. Using the GPS of your phone, combined with various existing mapping services, its primary purpose is to tell you where you are, and how to get where you want to go. The maps themselves can come from a host of different services (Mapbox, HERE, OpenStreeMap and Sputnik, amongst others) and in my experience they’re of high quality and accurate. You can choose from different layers (cartographic, satellite, hybrid, traffic) with both night and day modes which are ideal when driving. Excellent routing and navigation are supported. The display is really clear when driving, giving directions in good time and making it clear when to turn, which exit from a roundabout or motorway to take and so on. It will even provide voice navigation using one of the supported text-to-speech engines (Mimic, Flite, PicoTTS or Espeak). If you’re looking for navigation software on your Sailfish phone, then this is highly recommended. Available from OpenRepos and now also from the Jolla Store.
Thanks go to ninepine for suggesting we take a look at these two nice apps from anarchy_in_the_uk. Both MultiModal and National Rail cater for those looking to brave the public transport systems in the UK. The National Rail app provides info about “overground” trains. It’s better suited to live information than route planning, so if you find yourself at a station and want to get somewhere, it’ll tell you which trains are leaving in the next hour for example. I had some difficulty getting it to store favourite stations, but searching worked fine. Trains are nicely colour-coded by operator and selecting a destination will also tell you all of the stops and times in between. It’ll even let you view any announcements provided by the National Rail Service about a particular station (e.g. disruption or facility changes). That’s all great if you’re travelling around the country by train, but if your travel plans aren’t going to take you outside the capital then you’ll want to try MultiModal instead. Multimodal is still an early release, so there’s no app cover yet, nor an about page or settings; just an expectant-looking search box at the top of the page. Start typing and the screen will be filled with potential London destinations. It cover all of the TfL modes of transport: buses, underground, light rail and river crossings. Like the National Rail app it’s more designed for real time info rather than route planning. It has nice icons to represent the route types, and timings based on how long until the next arrival or departure. If you’re travelling the UK these will be really useful tools to have at your disposal (just make sure you check times before you descend into a signal-free underground station). Both Multimodal and National Rail are available from OpenRepos.
I may have mentioned before, but I’m always on the look out for good Sailfish OS games. Patience Deck from Tomi Leppänen (Tomin) brings a classic card game to Sailfish OS: Patience, otherwise known as Solitaire. Well, that’s not quite true, as it actually brings 45 different supported variants, along with another 45 that aren’t supported. All of them are card games and all can be played by a single person, so they’re great for idling away the time waiting in a queue, waiting on the bus, waiting for your code to compile. You get the idea. At its heart is a reimplementation of the GNOME Aisleriot game engine that you may have seen on your Linux desktop. The games themselves can be quite tough, requiring an unsurprising amount of, well, patience. No doubt you’ll have played at least one of the variants before, with Klondlike being the most widely known (and at one point apparently the most popular computer game in the world, given that it came with a free copy of Windows). Patience Deck has a number of nice features that make the experience more enjoyable, including nice and responsive card dragging, clear card designs, portrait and landscape modes, a timer so you can see just how badly you’re doing, and a hint system in case you run out of ideas. The latest release brings UI improvements, nicer animations and an option to stop the screen from blanking during a game. If you have some time to spare, grab yourself a copy from the Jolla Store or OpenRepos.
This is a community update, and frankly we can’t always keep up with all the exciting stuff happening in the Sailfish community. Plus, the less of this we have to actually write ourselves the better. So please help us out by posting your Sailfish news updates to the forum as a reply to this post. We’ll collate as much of it as possible into one easily digestable post for the next update.
And don’t forget to join us at the community meeting every other Thursday on IRC. It’s a great place to discuss any of the content you see here, or to share your ideas for future updates. The next meeting will be on the 3rd June, full details here.