Here in Finland the summer is coming to a rather abrupt end as we head into what is usually a very short autumn. But the changing seasons have also brought with them an autumn harvest of exciting Sailfish OS news to share with you.
The big event this fortnight has been the release of Sailfish OS Verla 4.2.0 to Early Access subscribers. If all goes to plan the release will roll out to all users soon and you’ll be able to read all about it on the official Jolla blog. Until then, it’s great to see all of the Early Access subscribers sharing their experiences on the forum here. At Jolla we keep careful track of feedback threads like these and also always try to take on board the ideas that come out from them. So while you’ll appreciate that we can’t commit to implementing any particular idea or request, we really do take on board your ideas. Please keep them coming.
The Verla 4.2.0 release brings many new features, bug fixes and improvements. Far too many for me to properly summarise here, and you should of course take a look at the release notes for a more complete picture.
From the user-perspective, you’ll find a new file-sharing flow with the file sharing dialogue overlaid on top of the app rather than a separate page pushed to the page stack. This is visually less abrupt so that you don’t lose connection with the content being shared. It also ensures greater consistency between apps.
This is also one of several improvements designed to make one-handed use of the phone easier, since it pins the sharing options to the lower part of the display. There have been other improvements in this regard elsewhere too. For example, the app grid is now “sticky”: if you pause while pulling open the app grid it will fix in place. One-handed selection of app icons at the top of the grid can now be managed much more easily by simply opening the app-grid only part of the way.
The Settings UI has also been improved with new icons in the App Settings pages and improved legibility. You’ll also find improvements to the calendar, some of which Damien covered in previous newsletters, but probably the most immediately obvious will be the new coloured bullets appearing below the dates in the month view. This makes the Calendar app both more functional and more colourful. Also you can now send emails to event participants straight from the Calendar app.
If you’re rocking a new Xperia 10 II you’ll see some exciting changes to the camera app. The big change is that all three lenses are now available for use. This means that alongside the main standard/wide angle lens (f/2.0, 26mm) you can now also take photos with the telephoto (f/2.4, 52mm) lens for close-ups, and the ultrawide (f/2.2, 120°, 16mm) lens for wide-angle landscapes. I’m no camera guru, but I’ve found the ultrawide lens can create some quite stunning scenery photos. Community members were big contributors to the backend changes that made this possible, with special thanks going particularly (but in no particular order) to: piggz, Mister_Magister and leszek.
There have been some significant changes to the browser UI, including a new toolbar, new menu and new tab management interface. These changes are ongoing, with Versa 4.2.0 representing an intermediate stage in the UI update. The next release will see these changes iterated on and improved upon. The latest Sailfish OS updated doesn’t bump up the underlying Gecko engine, but that doesn’t mean there haven’t been improvements there too. Significant work has been put into tightening the integration between the Sailfish browser UI and the engine, and in making the engine compatible with more sites. You should find immediate improvements when using the developer forum here, for example. But this also allows us to expose new features too: improved settings management, the option to choose where downloaded files are saved, improved password management, improved history, improved favourite management, and so on.
There have also been improvements to the sandboxing, including improvements to the clarity of the UI and robustness of the sandboxing. New permissions have been added for accessing SD cards and we’ve also been tweaking the other permission categories based on our experience with and feedback that we received from the previous release.
Android App Support compatibility has been improved with better support for camera usage (important for video calling), improved connectivity handling and many bug fixes. Pictures from the Android Pictures folder are now available in the Sailfish OS Gallery app in their own new virtual folder. Media handling has also been improved so that Android media apps can now be controlled using wired or bluetooth headsets, just like their native counterparts.
If you’ve been holding back from encrypting your home folder, you now have no excuse given the ability to use an SD card as temporary storage for all of your data during the upgrade process. There have been many interesting discussions on this forum about the security of encrypted devices, and further ways to build on the functionality that’s already there, Encrypting your device is a great way to improve your data security, while also preparing for any future improvements.
As a final note, predictive text is also now available for the Xperia 10 II (as before, as part of the paid Sailfish X features along with the Android App Support and Exchange capabilities).
That’s a quick summary of the user-facing features, but there’s also been a lot of work on “back-end” features aimed at developers for use in third-party applications. In fact, many of the front-end changes have been motivated by the desire to provide better APIs for developer use.
For example, the new file-sharing flow pulls the file-sharing UI out of your app and into a separate process. The nature of sharing content between apps is that the sharing app requires greater permissions and elevated privileges to work (in essence, the app you’re sharing from needs the same privileges as the app you’re sharing to). Splitting file-sharing into a separate process improves security by relaxing this constraint. It removes the need for apps which implement file-sharing capabilities from requiring all of these additional privileges and permissions. The change is therefore an important one in allowing file-sharing to be used more safely by third-party apps, and consequently it will also be added to the list of harbour-supported APIs. Thanks go to karry for submitting a request and associated PR to allow apps using it to pass validation. At time of writing apps can’t be accepted just yet, but this does mean that the process is underway.
While the Camera app has been improved for end-users, it builds on changes that had already been made for developers to get better access to device-specific camera features with many issues with Camera API usage fixed.
Last but by no means least, there have of course been numerous bug fixes throughout the entire operating system. Fixes to account handling, XMPP messaging, ambiences, CalDAV calendar support, connectivity, documents, email, Android security fixes and fixes specifically for Xperia 10 II and Gemini devices. The list goes on and as usual, there are barely any components that weren’t updated and fixed in one way or another.
This is just a summary and as mentioned, you should check the release notes for the gory details. Leszek Lesner has also created one of his trademark Early Access reviews. As always he manages to give really comprehensive coverage of the new features in a very compact and watchable form.
We really hope you enjoy the new features of the latest Versa update. Of course, at time of writing this is just the Early Access release. Keep an eye on the Jolla Blog, and your notifications view, for the rollout of the full release.
Sailfish OS has always stuck to a very clear point-release upgrade process. This means that just like with the Early Access Sailfish OS Verla 4.2.0 release we’re seeing now, there are periods when the release process is very public, followed by periods of relative calm in between. But of course, behind the scenes, although there’s certainly a cycle, there are never any periods when there’s nothing happening. Preparation for the next release (and the one after that) is an ongoing and continuous process. Jolla doesn’t generally talk publicly about future releases, since we prefer to focus on real software that is shipping and available right now. However, interested explorers can always (and often do) dig around in the public PRs to get an idea of what future features might be included in upcoming releases. Practically speaking, most of Jolla’s development process happens in public.
However, one area that takes up a great deal of time internally, but which gets far less exposure to public gaze, is the testing process that happens inside Jolla. It won’t surprise anyone here to know that testing is hard. As a great philosopher once wrote (actually it was the testing advocate and teacher James Back) “Testing is an infinite process of comparing the invisible to the ambiguous in order to avoid the unthinkable happening to the anonymous.”
Jolla has the benefit of a dedicated, highly-motivated and highly-professional team of testing engineers. Many of the team have a long history of working for Jolla and all are experts in the area of software testing. To better understand the Sailfish OS testing process we spoke to Jari-Pekka “JP” Walden, Jolla’s Test Manager, and Xiaobi “Bree” Xu, one of Jolla’s Testing Engineers.
As well as being the head of the testing team, JP is also an active reservist and instructor who this year received honours in the form of the Suomen Leijonan Ritarimerkki (Finnish Lion Knight’s Badge). JP joined Jolla in 2013 when he was looking for new challenges after over 10 years at Nokia and found that Jolla was looking for a test manager.
Bree’s role is to design and maintain test plans and report bugs within release testing. As a Chinese national working in a Finnish company in Finland, Bree describes herself as “bringing some wierd snacks that others never saw in their whole life to the office” (and which we all very much enjoy eating!).
We delved behind-the-scenes with JP and Bree to see how the testing team ensures Sailfish OS stays reliable and effective even while large and continual changes are being made to the operating system.
This is how the testing team describes the main goals they works towards.
- Identify critical bugs as soon as possible and communicate to the releasing team.
- Analyse tendency by comparing observations to previous states or results.
- Provide test results with kiwi test reports.
- Help developers to fix bugs by providing good bug descriptions, logs and all needed info.
- Improve test asset if needed, make corrections to test cases.
JP describes his role and that of the testing team somewhat more succinctly.
The Test Team’s main purpose is to verify the quality of the releases and new features. I’m coordinating the testing and doing the testing as well.
“My main role is to design and maintain test plans, and to report bugs within release testing. As well as the routines of release testing, I also do SDK testing and work as a gatekeeper in Harbour (reviewing apps submitted to be shown up in the Jolla Store).”
To achieve their testing aims there are actually many different types of testing that the testing team applies. A default Sailfish OS install includes nearly a thousand separate packages, and the Sailfish repositories contain over eight thousand packages, all of which have to be tested whenever changes are made to them. Automated testing is therefore an important component in the testing process. Many hundreds of automated unit and integration tests are run as part of the development process. Individual developers will run unit tests as a natural part of their development regime, but these hundreds of automated tests are also run daily on dedicated phone-hardware to identify any regressions that might have been introduced.
Alongside these daily automated tests, the testing team also works closely with developers as part of the bug-fixing or feature development process, as JP explains.
We have dedicated testers for each developer team and these testers are running feature testing in close co-operation with the developers. Naturally also developers are running unit tests and test automation is used as well.
This process begins once a PR has been created for a particular repository. It falls to the testing team to build the package to be deployed to a test device, work with the designers and developers to craft test cases, then perform manual tests to check that the functionality performs as expected and doesn’t introduce regressions elsewhere. The process isn’t perfect of course: it’s very hard to ensure that no regressions have been introduced by a change. This is especially true for bug-fixing changes, which are known to be the most-likely changes to cause regressions or introduce additional bugs. It’s also a highly-skilled process, requiring deep knowledge of packages, the operating system and end-user use-cases.
But that only covers a portion of the testing team’s activities. Another high-level task that’s particularly relevant as we roll out Sailfish OS Verla 4.2.0, is that of Release Testing. The Testing team work closely with the Release team to make this happen, as Bree explains.
The Release Manager Jorma [Virkkunen] manages the release process. Bugs reported during release testing are efficiently raised to the development team according to their priority and severity. Although the test cases involved in the release process are limited to a sanity set, they cover the essential and important features and functions of Sailfish OS.
As Bree suggests the tests the Testing team perform are split up by test plans and test cases. Here’s JP again.
In release testing we are running a pre-defined test plan for certain devices in order to make sure that the functionality and the quality of the release candidate is at a good level. This takes usually 4-7 RCs/test rounds. Both automated and manual testing is performed for the RCs. Kiwi is our test case management tool where we have stored our test asset and which we are using to create test plans, test runs and store test results.
Each release candidate as JP mentions is a versioned set of components that represent a snapshot of all the Jolla repositories at a particular time. For most repositories this is captured as the SHA hash of a particular commit, but in some cases, such as with the sailjail-permissions repository, you’ll see that there’s an
upgrade-4.2.0 branch, which most likely means that specific changes were needed for the 4.2.0 release (usually meaning that changes were backported to the branch). All of the packages are built by OBS and are then combined to create a set of release candidate (RC) images (one for each supported platform) that can be flashed directly to phones for testing.
The test case management system (TCMS) Kiwi that JP mentions is a crucial tool in managing the process, especially when it comes to manual release testing. Kiwi allows individual test cases to be written up, then grouped into larger test plans that relate to individual releases and devices. Bree gives an idea of how important it is.
Kiwi is a strong test case management tool. It holds more than 6000 test cases, supporting test plans and runs. It is not only used by OS release testing, but also SDK release testing.
Each individual test case in Kiwi is a description of the manual steps a tester needs to go through in order to test a particular feature or to check the absence of a particular bug. There are many situations in which it’s just not feasible to test features or bugs using automated processes, so these manual tests are absolutely critical for ensuring that Sailfish OS releases reach the standard that we expect of them. Let’s take a look at the process described in one of the simpler test cases taken from Kiwi.
TC-47: Automatic device connection Actions: 1. Testing device is paired and connected with Bluetooth speaker. 2. "Always allow connections from this device" is enabled in paired device settings. 3. Power down Bluetooth speaker 4. Wait until connection lost (e.g. follow Bluetooth settings view) 5. Power up Bluetooth speaker 6. Wait until connected (e.g. follow Bluetooth settings view) 7. Play music (e.g. using Media application) Expected result: 1. Automatically connectable paired devices can connect and playing audio is routed to Bluetooth speaker.
The test case summarised above is one of the many test cases contained in the “Basic Release Test Plan” that will be checked for every device and for every release candidate. As Bree explained above, there are currently well over six thousand individual test-cases like this recorded in Kiwi. Separate test plans will also be drawn up for individual devices and individual releases based on known features, bugs and regressions that have been worked on for the particular release.
As I’m sure you can imagine, testing new releases at this level of granularity is a time-consuming and intensive process. In case one of the tests fails, a bug report will either have to be created or re-opened. This then goes back to a developer for more work, and may result in the need for a new release candidate if the bug is considered to be a release blocker. It’s quite common (actually more like inevitabile) for there to be multiple release candidates needed before the final version that’s rolled out to the public. Bree explains how this works out in practice:
Every release candidate takes 1-2 weeks to test and conclude the results. There are usually 4-7 release candidates in every release cycle, depending on the size of release, bugs reported, and if there are any regressions. Approximately it takes 1-2 months for a release to come out from start.
As you can imagine this process is highly resource- and time-intensive. It’s made possible by the dedication of the testing team, but as JP explains, also because the team is able to draw on resources from elsewhere as well.
Our testing resources are limited and therefore it is great that all the sailors are basically “testers” as they are using Sailfish devices in daily usage and reporting bugs. The test team focuses on testing new features and ensuring the release quality.
This is particularly important for the “day-to-day” usage that picks up bugs that are hard to detect by working through the repeatable test cases alone. As Michael Stahl, software validation architect at Intel famously wrote in 2017 “Irreproducible bugs become highly reproducible right after delivery to the customer.” All sailors use Sailfish OS phones as their
main daily devices. However JP continues that input from the community is also particularly important.
The community is helping us with the testing, we are sharing RCs with particular members during the RC testing process and naturally all the feedback we get from them is very valuable, and it would always be great to receive more comments about the RCs. Since we in RC testing are mainly using devices which are just directly flashed (so the device is basically empty) we might not see some issues community member might see (they have devices which have been in real life usage and they are using operators/environments we are not).
The importance of the impressive input that we receive from the community is never underestimated internally at Jolla, even if it doesn’t always get discussed publicly. When I ask JP if there’s anything he’d particularly like to highlight, he goes out of his way to emphasise the importance of community input, and that if there are things that Jolla can improve about its processes in order to support the community better, that would be good to know as well.
It would be nice to highlight that feedback from the community and especially the community testers is very welcome. It would be nice to get feedback if the community is hoping to receive some more support from Jolla in order that they could then give us more comments about the releases.
If you’d like to support these efforts, the best way is to join the Early Access program and comment on the releases as early as possible. It can make a real difference to the release quality. We’d love for the latest Sailfish OS Verla 4.2.0 release to be bug free, but of course this isn’t a reasonable expectation in reality. Until we’re all upgraded to the next level of human existence and are able to develop entirely error-free software, we still look to the superb testing team, and the diligent efforts of our valued community, to help maintain our high quality standards. Thanks to JP and Bree for allowing us a peak inside this process.
Quite an eclectic collection of beautiful, functional and feature-rich apps this time. As always, we couldn’t possibly fit in all of the new and updated apps, kudos to all the amazing developers out there, but we’ve picked a few to share with you. And they really are a nice bunch.
The first line of the description of Swiss Clock in the Jolla Store is “Just a clock”. While there’s some truth to this, if you want to enjoy smoothly animated clocks with classic clock faces, then Swiss Clock is worth taking a look at. Released by prolific app developer Slava Monich (slava), it actually offers three different clock face designs, and only one of them is the classic Swiss Railroad clock that gives the app its name. This Swiss Railroad clock face is similar to that designed by Hans Hilfiker in 1944 used in train stations throughout Switzerland and which Apple famously licensed for use from the Swiss federal railway back in 2012. In addition you’ll also find here designs similar to that used by Deutsche Bahn and in the Helsinki Metro. Each design supports both light-on-dark and dark-on-light styles, switched between by double tapping inside the clock face. A single tap outside the clock face will reveal or hide some numerical adornments to the clock.
The clocks themselves are crisply presented and really smoothly animated. Crucially the lovely internal presentation is also replicated on the very clear cover page. The only thing missing for me is an audible clunk as the minute or hour hands advance. Having grown up in a house with a grandfather clock, while sometimes satisfying, it can also get agitating at times, so maybe it’s for the best. The latest version includes Hungarian, Dutch and Swedish translations. There’s not a great deal to translate if I’m honest, but these are certainly good to have. The latest version is available from the Jolla Store and OpenRepos. The version available from OpenRepos has slightly more functionality in the form of a Settings page in the Settings app to control orientation features.
Imageworks is a real gem of an app. Put simply it’s an app for making edits to the images on your phone. But that hardly does it justice. It includes a plethora of editing features that allow you to manipulate your image in a whole variety of ways, allowing a level of customisation that would put some desktop photo editing apps to shame. In fairness, this isn’t an alternative to a drawing or painting program, it’s squarely focussed on making touch-ups to photos rather than original works of art. But that’s more a limitation of your phone’s small display than it is the capabilities of the app.
The basic and probably most used functions are likely to be the cropping, rotating and colour-tweaking options (e.g. brightness or gamma-curve editing). Some care has clearly been put into making these tools functional and useful on a small screen device, with clear finger-ready controls including nice large control points that can be dragged around easily. On the more artistic side of things it allows you to perform direct drawing onto an image, either free-hand or using one of the pre-defined shapes (points, lines, rectangles, icons, etc.). You can also overlay text captions, or apply one of the 31 more artistic filters (from simple contrast control to full-on fisheye effects). Here there has also been a lot of care put into the UI, with a nice drag bar for comparing the before-and-after effects.
All of the effects can be undone, and edits aren’t stored permanently until the file is re-saved, so it’s a good environment to experiment in. The biggest downside of the app is that editing actions can take quite a while to be applied, particularly when using the default resolution of a camera-captured image. This can make experimentation a little more cumbersome.
Nevertheless, this is really a great addition to the Sailfish app ecosystem, and Mark Washeim (poetaster) deserves much credit for adopting the app from original developer Tobias Planitzer in order to continue its development. The latest version has benefited from some QML restructuring, an aarch64 build and updated Python image processing libraries. Get yourself a copy from the Jolla Store or OpenRepos.
In the last newsletter we discussed some of the ways developers can keep their apps consistent with the standard Sailfish style. While some apps may bend these conventions here and there to add the occasional stylistic flourish, QuasarMX takes conformity-busting to the next level. Make no mistake: this is a music player with attitude. It’s reminiscent of how Nullsoft ploughed its own furrow with Winamp back in the day. But while QuasarMX may not care too much about convention, it’s hard not to be pulled in by the enthusiasm of developer Andre Beckedorf (evilJazz) and publisher Meteora Softworks (as the About page makes clear: “Crafted with love while listening to lots of music”).
And while it may not follow the Sailfish style guide, it’s no less beautiful or easy to use for it, nor does it eschew integration: it offers full MPRIS support and a very nicely designed cover. Inside the app is built around a carousel of tabs: music selector, albums, track list, music player, music info, metadata downloads and and mixing.
It’s worth noting that not all of these functions are available in the free version. You have to upgrade to get mixing and equalising features for example, at a cost of €12. Although this freemium model isn’t so common in the Sailfish world, if you like the app and plan to use it long-term, then this is a small price to pay to unlock the pro features. Meteora gives every opportunity for you to decide whether or not it’s a worthwhile investment, given that you can temporarily unlock the pro features to try them out. It all seems very fair.
There are, frankly, too many different features in the app to go into detail here. There are of course many other music players available for Sailfish OS too, including Jolla’s default player, as well as others we’ve featured in previous newsletters. If you’ve not yet found your music-player nirvana, then I strongly recommend giving QuasarMX a go. If you can deal with its lack of conformity, then I don’t think you’ll find a more polished or full-featured music app on Sailfish OS. The latest version offers improved Bluetooth support, improved sleep timers, optimisations, bug fixes… it’s quite a list. QuasarMX is avilable from the Jolla Store or directly from the Meteora Softworks website.
The freemium model of QuasarMX is similar to the model used previously by WerkWolf Software for its Piepmatz Twitter client. WerkWolf converted Piepmatz into fully-free software back in November 2019. Piepmatz is now free-as-in-beer while also being free-as-in-speech, released under a GPLv3 licence. The author, Sebastian Wolf (WerkWolf), produces prolific updates (averaging a monght and a half between updates in 2020) and shows no sign of slowing down.
But what of the app itself? If you’re a Twitter user then it really has a lot to offer. All of the basics are there, with images, image captions, videos and embeds all supported. All of the different ways for interacting with tweets are supported, so you can express exactly your level of interest by choosing an appropriate way to respond: reply with posterior comment, like, retweet, retweet with a prior comment, or participate in Twitter’s crazy threading model by replying to a replier. There’s more than enough scope for easily-misinterpreted subtlety. But we can’t blame Piepmatz for Twitter’s failings. The app is comprehensive and makes reading Twitter threads as easy as can be expected.
When composing new tweets you can attach images from your gallery and there’s a clear indicator of how much space is left. It’s not currently possible to tweet videos, and it would be nice to be able to compose multi-tweet posts, but these are minor issues. The app has far more really useful features such as the ability to manage multiple accounts, broad emoji support, comprehensive customisability, all things which are arguably more important for the majority of users.
Twitter has long been one of the most accessible social networks for Sailfish OS users, primarily due to its open API and direct integration with the OS and notifications screen particularly. Piepmatz gives Sailfish OS users a first-class client with regular updates that keep on top of the API changes Twitter continue to make in the background. The latest update has done just that, removing a deprecated Twitter API while also adding emoji 13.1 support, with improved translations and some housekeeping changes. It’s fully recommended and available from the Jolla Store and OpenRepos.
As sharp-eyed community members noticed, a recent TechCrunch article covered Jolla’s levelling-up to profitability. The article includes a fascinating interview with Jolla’s CEO Sami Pienimäki as well as talking about some of Jolla’s future plans. It’s well worth a read.
An interview with Sami Pienimäki also appeared in Finnish national newspaper Kauppalehti this fortnight. You’ll have to pass through a few hurdles to read it (it’s paywalled and written in Finnish), but it touches on some similar topics to that of the TechCrunch article, including demand for Jolla’s technologies from the automotive industry.
Looking more closely at the automotive industry and Jolla’s potential role on the dashboard is a recent article from autoevolution, that we’re sure will be of interest as well.
One of the topics you’ll notice discussed in all of these articles is how Jolla has been identifying opportunities related to the automotive sector, especially in relation to AppSupport for Linux Platforms. As Sami explains in the TechCrunch article:
There’s been a lot of, let’s say, positive vibes in that sector in the past few years — newcomers on the block like Tesla have really shaken the industry so that the traditional vendors need to think differently about how and what kind of user experience they provide in the cockpit.
To help capitalise on these opportunities, Jolla are currently looking to hire a driven, ambitious, Automotive Sales Manager with ideally 3-5 years of international business development experience, willing to work within Europe either remotely or on site but also with a willingness to travel.
If you’re interested, or know someone who might be, please take a look at Jolla’s career page for more info. Even if you don’t know of anyone, you can still help Jolla find the right candidate by sharing the info to your contacts on Twitter, LinkedIn, Facebook or whichever social platforms you inhabit.
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 9th September, full details here.