Somehow, without any forethought or planning, this fortnight’s newsletter has become coffee-themed. We have news of an update to the forum software, to improve your reading while enjoying a coffee. We point you at some motivation to give someone else a coffee. And we discuss Java, the king of coffee-based languages. We’re very happy that Damien Caliste (dcaliste) is back once again to guide us through the Sailfish OS repositories, and we finish off by rounding up all the latest and greatest Sailfish OS app updates.
Whatever your beverage of choice, we hope you enjoy.
Although you may not have realised it, there’s every chance you’re reading this newsletter on an entirely new forum. Don’t worry, this doesn’t mean posts or functionality disappearing, but rather an upgrade to the Discourse 2.8 forum platform. Jolla’s forum-meister Ville Nummela (vige) explains what’s going on.
“The changes, at least those visible to users, are quite minor. We are aware that the new version is not compatible with older Sailfish browsers, so people should not file bugs unless they are using Sailfish OS 4.4.0 or later. Otherwise, for what to do in case of glitches, it’s the usual: File a bug report ”
In terms of changes that you may see, expect some visual style improvements, better management for draft posts, and various visual tweaks to make it clearer which posts you’ve already read. In practice it should mean relatively minor changes for most users, but we hope they make your time here in the forum even more enjoyable.
Coffee. Mmmmm. Like many parts of the world, we do like our coffee in Finland. That’s why we also know that coffee is a great motivator and energiser when it comes to producing code. So anything that helps get coffee into the mouths of the devs who need it has to be a good thing.
The big Thank You & Coffee thread aims to do just that. There are rules to follow if you want to join the thread, but Enrico (enrish) explains them succinctly in the first post, with helpful capitalisation of the important bits:
- Every single post must be preceded by a coffee to the dev (which means sending them a financial donation).
- Say thank you only for one app per post.
- Likes are not allowed.
So if you’ve every thought it might be good to send a small donation in the direction of the developer of your favourite app, but never quite got around to it, then hopefully this will provide the nudge you need.
Spaces or tabs? Emacs or Vi? Presidentti or Nordquist? C++ or Java? The answers to these questions give an insight into a person’s soul that might otherwise take a lifetime to uncover.
For a long time Java has been an exception to this: it’s not a compiled language, but it’s not an interpreted language either. It compiles down to bytecode which requires a native Java Virtual Machine (a “JVM”) to run.
Putting Android App Support to one side for the sake of simplicity, Sailfish OS doesn’t ship with a JVM, so building Java applications to run natively has been out of the question.
So, when we heard of a project to bring the Java programming language to Sailfish OS, our interest was piqued.
The initiative comes courtesy of Thilo (thigg) who describes himself as “a 30 year old software engineer from Germany”. Thilo knows a thing or two about Java, working as a consultant specialising in Java for a small company.
You may know Thilo from his involvement in various Sailfish OS projects, including helping to maintain podQast, creating the hydrogen Matrix client and being an active part of the Bug Coordination Team.
Thilo’s Sailing-to-Coffee project aims to allow Java code to be fully integrated with Sailfish OS apps, without the need to run a Java Virtual Machine in order to use the app. Quite apart from the ability to write completely new Java code to run on Sailfish OS, this also makes the massive corpus of existing Java code available as well, something that Thilo explained to us when we spoke to him recently.
Java is all around, or at least JVM languages like Kotlin and Groovy are. With this comes a huge ecosystem of libraries. In recent years Java became more performant, friendlier to develop in and less memory hungry. Since a few years Oracle has been developing GraalVM which contains the Graal Native Image. This allows you to build native executables or shared libraries with a minimal runtime packed in.
I wanted to try out the native builds and wanted to see if native Java applications provide a benefit to Sailfish OS app development. Sailing-to-Coffee tries to explore a way that allows using Java code in this way.
It’s worth pausing to think about that for a second. The Java language is more than just a compiler. It’s a framework that includes compiler, libraries and the JVM which requires tight integration with the host system. It includes capabilities that range from Big Number support to networking and more. Boiling that down to something that will run in combination with the existing Sailfish OS app development process is no mean feat. Thilo explains it like this:
JVM Languages like Java compile into Java bytecode. Bytecode is a very low level (a few different instruction types) representation of your program. So there are two paths.
Either you hand the bytecode to a virtual machine (the JVM for example), it interprets the bytecode, optimises it during runtime and executes it. This is the “traditional” way of executing a Java program. Applets worked that way (they are quite dead now) and most other classic Java applications. The classic Java Runtime Environment (JRE) contains a lot of stuff, and lots of that is loaded upfront. Thus the footprint here used to be quite high (until project Jigsaw).
Or you compile it into something else. Most famously done by Dalvik, the JVM runtime for Android. This compiles the bytecode into Dalvik bytecode, which is then executed by Dalvik. This allows quite a few optimisations on the way. This is not totally native, but quite close.
The Graal Native Image does the last bit: it compiles all the way down to native and you don’t need a runtime anymore, it is included in your binary. The “runtime” here is called SubstrateVM.
The result from all this work is that Thilo is able to compile Java or Kotlin code into a shared library which can then be linked against a C++ binary, including those that build on top of Libsailfishapp.
The first demonstration of this approach comes in the form of a game for Sailfish OS: Sailing-the-Flood-to-Java.
I was looking for inspiration and scrolled through F-Droid. Open Flood was what I was looking for. I wanted to try to reuse code from an existing Android app, but it needed a simple GUI because I had to build this myself. As it goes, there is not too much left of the original code from Open Flood
The result, flood-java, is about to be released. I got a friend to design a logo for me, now I need to fix a few bugs and wait for Jolla Store approval.
So expect the game to be available in the Jolla Store very soon, at which point you can enjoy it’s calming colours and simple rules without ever having to worry about all of the heavy tech that went into it. “What I like about flood-java”, Thilo explains “is that it does not have many rules. You can set your own goals, try to optimise your strategy or just enjoy some clicking around.”
Thilo makes the interesting point that while flood-java is just an output from his Sailing-to-Coffee journey, it’s also been an essential input to the process too.
Sailing-to-Coffee was the base of flood-java, but will also be the endpoint. With all the knowledge I gathered, I’d like to think about a library which helps building applications in the same manner. And I’d like to have more people involved into that.
Since all of the interaction with the Qt layer is still handled on the C++ side, apps like flood-java that are developed this way retain their fully native feel: a Sailfish Silica UI, app covers, and so on. But mixing code from different languages always introduces interoperability challenges. Primitive types may have different byte ordering or sizes for example, and more complex types just add to the, well, complexity. A necessary part of getting Sailfish-to-Coffee to work has therefore been choosing a suitable interoperability layer, so that data can be shared between the C++ and the Java code.
This is one key area where flood-java provided important insights.
Sailing-to-Coffee follows the idea of pyOtherSide, offering a single entrypoint into your Java application. You send data and a methodhandle over, you get data back. In Sailing-to-Coffee this is all done via JSON.
With flood-java as a tech demo, I tried to explore the limits of this, especially performance-wise. The field in flood-java is an array of shorts (16-bit signed integers) and I wanted to see how huge of a field works. With 250 squared that’s 62500 shorts, as a JSON array in utf8 it is at least 62500*2 bytes (number + comma) = ~122 kb. Serialising and deserialising the JSON especially in QML seemed to take time.
To try to avoid this overhead, Thilo switched from JSON as an interoperability datatype to using Flatbuffers, which pack data into a much leaner, but still language-neutral, format.
Flatbuffers allow for a more efficient binary storage layout, especially if you don’t have to unpack it, you can directly read from it (I guess that’s why those buffers are “flat”!)
You compile the schema into Java classes and C++ classes and include those in your application code. You now use those classes and Flatbuffers takes care of serialising the data for you.
Thilo isn’t certain how much of a speed increase this gives over using JSON, but is nevertheless pleased with the final performance of the app. “I was generally surprised how well it works” he says “Initialisation seems to have almost no overhead. I would expect it to perform better than most Python code we see in apps”.
He also points out that he’s working on improving performance through tweaking the GraalVM parameters, and that he’s already managed to get the memory footprint at runtime quite low. His flood-java app requires only around 18 Mb for example.
Thilo has big plans for both flood-java as an app, and Sailing-to-Coffee as a process. He hopes it might even allow Java to become a more accepted part of the app landscape on Sailfish OS.
I would hope that Java actually becomes a normal language option. But we are not there quite yet. However if people show interest we might be there sooner than expected.
Pull requests are welcome. Sailing-to-Coffee needs to become a nice and usable project. I was thinking about a public call-for-AIs for flood-java after I create an interface for an AI-Opponent. Most of it is public domain. I want to encourage other people to take the code and build with it. Help is appreciated as well. If you have questions feel free to contact me, for example here on the forum.
Java remains a controversial choice of language for Sailfish OS. But for many developers it may be just what they’re looking for. Credible studies have shown that while it’s source is verbose compared to scripting languages, and with slower execution time compared to procedural languages, it compiles down to smaller executable and has runtime performance that beats scripting languages and even approaches that of C. It also has strong typing, garbage collection and avoids some of the more flamboyant distractions of newer languages. In Thilo’s words: “Its boring. And that’s a good thing.”
Let’s hope Thilo’s amazing work will pave the way for more coffee-based apps to be developed for Sailfish OS.
It was already mentioned during the last community meeting on IRC, and the various commits of the last 15 days confirm it, there will be many new API allowed in harbour with next Sailfish OS version. This is visible with changes to
sdk-harbour-rpmvalidator repository, but it becomes also possible thanks to the upgrade in documentations of the various implied packages.
Another noticeable direction pointed by the recent commits, is the work on making builds reproducible. This is an important measure to check against regressions during development and deployment.
lipstick, the compositor and main user interface of your phone, Tomin1’s pull request about supporting an
X-DBusActivatablekey in desktop files, has been approved.
timed, time and alarm handling daemon, the pull request from teleshoes to allow the
MaximalTimeoutSnoozeCounterattribute to be set, has been reviewed and merged. This would allow a snooze counter to be added via the command line.
buteo-sync-plugin-carddav, a plugin for synchronising contacts, HenkKalkwater has proposed a pull request to fix CardDav syncing with NextCloud servers where the
.well-knownindex redirect omits the hostname. This addresses the bug raised on the forum about the issue. The fix has been accepted and merged after some review from pvuorela.
wpa_supplicant, for accessing WPA and WPA2 protected WiFi networks, Thaodan and pvuorela continued their work to upgrade to the upstream version 2.10.
gecko-dev, the browser engine, rainemak is proposing to remove specific Sailfish OS skinning of buttons, inputs or textareas, as suggested by minman on this forum.
user-managerd, a daemon used for managing Sailfish OS device users via DBus, the pull request to guard against user files being removed for the system user, from krnlyng, has been merged.
sdk-build-tools, a package of scripts used to build the Sailfish SDK, martyone’s pull request to include a manifest file in the sdk archives, has been accepted.
sdk-setup, the pull request to fix a bug that prevented arguments being passed through from
%make_buildis used in an application’s spec file, from *martyone, has been merged. Also from martyone, the pull request to allow a broader range of tag names in projects to be picked up by the build process, has also been merged.
sdk-harbour-rpmvalidator, the harbour validation scripts, vigejolla added Sailfish Secrets to the allowed API in harbour, but also its QML plugin. Qt Location (up to version 5.4) will be allowed (Qt Positioning was already allowed). Using Mpris QML bindings will also be allowed in harbour with next Sailfish OS version, through the use of
python3, the popular and widely used programming language, Tomin1’s pull request to update the python3 package with a patch from Fedora so that
rpmbuilduses a timestamp from the changelog, has been approved.
qtscenegraph-adaptation, linking QML with hardware support, herrie82 contributed improvements to the code to be able to compile with more recent versions from Qt. These patches were used in LuneOS.
rpmlint, a tool to check if packaging into RPM is following good practices, martyone pull request to ignore warnings with OBS builds has been merged.
sp-stress, tools for creating stress test loads, martyone is proposing a pull request removing volatile information (like date and time) of the run, so stress logs can be checked over reference ones without spurious false positive results.
hw-ramdisk, tools to be used to create init ramdisk for booting Sailfish OS, martyone has a pull request that remove modified time information when creating an inode, in order to obtain ramdisk independent of the moment they were created.
sailfish-setup, create Sailfish OS specific users and groups, krnlyng has added 4 new groups (
appsupport-media_rw) and one user (
appsupport-root) to the base system.
nemo-qml-plugin-dbus, a plugin to can DBus from QML, zeno-sole contributed packaging rules to create a Debian package (beside the RPM one used by Sailfish OS).
build-compare, scripts to find out if the build result differs to a former build, martyone is proposing to upgrade the package to upstream version from 2022-06-20.
sailjail-permissions, the definition of the sandboxing permissions, vigejolla moved the permission definition to use functions related to encryption from the private list to the public one. Applications accepted in harbour will be allowed to list
Secretsas a new permission, when required. olf0 is proposing to rephrase the description of the
Compatibilitypermission to clarify its role. olf0 is also proposing to link the various permissions listed in the README file to their respective description pages in documentation.
sailfish-secrets, a framework to use encryption techniques, vigejolla fixed documentation ensuring that the mentioned includes are correct. He also completed the QML documentation with an extensive pull request.
docs.sailfishos.org, the documentation website sources, many changes already visible have been pushed so far:
- vigejolla added a page on how to use an application debugger for beginners.
- neomilium contributed the cheat page by adding import / export command line instruction for the call log and messages.
- rainemak merged the “development” and “deployment services” boxes on the main page.
- martyone added a new page briefly explaining application permissions and centralising links to more detailed pages.
- vigejolla updated the page describing harbour allowed APIs to match Sailfish OS 4.4.0 version status.
And some new changes have been proposed but are still pending:
- saukko is working on a proposition to simplify the documentation related to the open source parts of Sailfish OS.
- thigg is proposing to add a troubleshoot section to the QMLlive documentation page.
- rainemak is clarifying the use cases for platform SDK (with respect to the application SDK).
- rainemak is adding command line tips to allow (or remove) the weather application from partner space.
- vigejolla is cleaning the API page to point to the harbour page of the documentation instead of the raw source code files.
qtlocation, Qt modules to handle positioning and location, vigejolla enabled packaging of the documentation.
htop, a process monitor in terminal, Nephros proposition to upgrade from 3.0.2 to latest 3.2.0 has been merged.
You can’t yet get flood-java from the Jolla Store, but rest assured it’ll be featured here when you can. In the meantime, we have another new release and three other excellent app updates for you that you won’t want to miss.
Having taken my first steps into stop motion animation using poetaster’s new Stopmotion app, I was excited to try out TimeLapse Tools, a new suite of tools for creating time lapse videos from Sailfish OS developer veteran Lukáš Karas (karry). While there seems to be a lot of cross over, stop motion and time lapse are not the same thing. The former involves the creator configuring a scene frame-by-frame, while the latter often involves capturing real-life movement. For the final accelerated output a stop motion video will appear to run at real-world speeds. On the other hand a time lapse video condenses time so that everything appears to run at a higher speed. This can reveal a flow that might otherwise be hard to appreciate: the swirling of clouds in the sky or the undulation of the tides.
Like Stopmtion, TimeLapse Tools combines two separate stages: capture and assembly. In the first stage you can use either one of your phone’s inbuilt cameras, or hook up one of the many supported standalone cameras. The app allows for a good level of customisation of the camera, including exposure and focus modes. You can also crucially set the capture interval to allow for different levels of speedup.
No matter whether you’re using your phone’s or a separate camera, and tripod is pretty-much essential. Hit the vibrant “record” button and leave your camera for a couple of hours (or days) to capture its subject matter.
In the second stage you can either stitch the photos into a video directly inside the app, or export them in case you want to perform something more elaborate. If you choose the former you’ll still get options to set the video resolution, frames per second and processing to reduce flickering.
I’d like to say the results from my own testing were good, but while the app didn’t let me down, my lack of artistic skills and patience did. But with the app available it’s worth persevering, as with the right subject matter and a good eye, I’m certain it can produce excellent results.
At version 0.1 this is the first release of TimeLaps Tools for the Jolla Store and its already showing real promise. Alternatively the same version is also available from OpenRepos
Zollstock by Samuel Kron (black_sheep_dev) is becoming somewhat of a regular feature, having appeared in three out of the last four newsletters. Given this I’m not going to dwell on the details, but for those who don’t already know, it allows you to convert your phone into a surprisingly usable distance measuring tool. The clever draggable guides allow you to measure up to two metres in length using the edge of your phone as a ruler of sorts.
It’s excellent to see Samuel continuing to push updates out so frequently. The latest update adds Russian translations to the app courtesy of dimoon91.
Version 0.2.2 of Zollstock is available from both the Jolla Store and OpenRepos.
Another app that’s becoming a regular feature (two out of the last three) is SeaPrint from Anton Thomasson (attah). Like Zollstock it’s also focused on functionality, but instead providing a digital equivalent to a physical thing, SeaPrint does the opposite, allowing you to print all of your digital documents in physical form. While we must have turned the tide of the paperless office by now, there are still some things that only properly work when they on physical paper, and for those occasions SeaPrint does a superb job. As long as your printer is networked, and as long as your document format is supported (there are too many to list here, but PDF, image files, Microsoft Office, ODF and text are all there) then it makes the process super simple.
And you can even use it to print from other apps using the SeaPrint Share Plugin.
The latest release brings SeaPrint to version 1.2.1, which adds support for custom page ranges and decreases the time it takes to send documents to the printer by disabling anti-aliasing. You can get it now from the Jolla Store.
There was a time when you couldn’t open a Twitter feed without being bombarded by mysterious yellow and green blocks. Thankfully the craze for sharing daily WORDLE results has subsided, but the game remains a taxing yet satisfying way to pass the time. This version from prolific app creator and Jolla dev Slava Monich (slava) retains all of that satisfying gameplay, but without being restricted to just one puzzle per day.
The aim of the game is simple: guess the five letter word within six attempts. After submitting an attempt the app reveals which letters are correct and in a correct location, as well as which are correct but in an incorrect location. An extra catch prevents you reusing incorrect letters in future guesses. It sounds simple, and it is, but also surprisingly challenging.
A particularly nice feature of Slava’s implementation is that it comes with dictionaries for nine different languages, with Portuguese a new addition for this release. Version 1.0.10 also adds the option to display a timer to add that extra bit of pressure.
We hope you enjoy this community news, which we’ll continue to refine over the coming months. This is your news, and frankly we can’t always keep up with all the exciting stuff happening in the Sailfish community, so please help us out by replying to this post in the forum if you’d like to see something included.
And do also join us at our community meetings on IRC, Matrix and Telegram. It’s a great place to discuss any of the content you see here, ask questions and share your ideas. The next meeting will be on the 1st September.