Sailfish OS update from Jolla
In the past couple of months, we have been working on adding support for 5G networks to Sailfish OS. I had a discussion about the progress with mal, who many of you know from his porting efforts. He has been the leading software engineer on this project.
What is the current status of the 5G support?
Currently 5G is working quite well on Xperia 10 III which is the first officially supported device to have 5G hardware support. Both standalone and non-standalone 5G networks are supported.
The main selling point of 5G is improved bandwidth. What kind of speeds can we achieve?
The mobile data subscription that we use for testing has a maximum speed cap at 300Mbps. We have achieved that, so we don’t really know what’s the actual limit.
[edit] Indeed, the phone doesn’t seem to be the bottleneck here, as we can see from the screenshot below that abranson kindly provided:
I understand that this has hasn’t happened by just flipping some bit somewhere in the stack. What kind of changes were required?
Most of the changes were done to ofono-binder-plugin to support newer IRadio binder interfaces and adding the handling of the new network type. Other supporting larger changes were added to libgbinder-radio and ofono. Also smaller changes to handle the new network type were needed in libgofono, libqofono and libqofonoext. The changes most visible to user were done to lipstick home screen and settings app.
The work has not been completed yet. What is there still left to be done?
So far 5G works for native Sailfish applications. Integration of 5G support to AppSupport is still work in progress.
How about release schedule?
We’re targeting 5G for the next major Sailfish OS release. This depends on the AppSupport 5G integration progress.
App roundup
Browsing the Web is an essential smartphone capability, which is one of the reasons Jolla has invested so much in the Sailfish OS Mozilla-based browser. It’s an exceptionally complex and capable tool, and with Web standards developing all the time, needs continual development.
But while the Web is ever-changing, at the heart is a set of standards which remain surprisingly resolute. HTML, CSS, Javascript. And with an increasing focus on accessibility — screenreaders, non-graphical browsers and the like — there is now more incentive than ever for developers to ensure their sites degrade gracefully.
When I tested out terminal emulators a couple of newsletters back, I wanted to test them with apps that would really push them. “What better than a terminal-based Web browser?” I thought. I was a bit surprised to find that the usual suspects have only been built for 32-bit ARM devices. Kabouik of Literm fame, and Niel Nielsen (NielDK), have both done an excellent job porting command line applications to Sailfish OS, but sadly haven’t updated them for 64-bit.
To remedy this I’ve added what I consider to be the most promising text-based Web browers — lynx, w3m and elinks — to the Chum repositories for all architectures. All three are terminal-based tools for browsing the Web, but all three have different levels of compatibility and different levels of user-interface sophistication.
So what are they and what are they good for? Let’s take a look and find out.
elinks
While there’s no doubt that elinks is a text-based Web browser, of the three we’re considering here, it’s the closest to what you might consider to be a full browser experience. It doesn’t support images, but like the other browsers it supports the standard static HTML tags. Uniquely though, it also has rudimentary JavaScript support using the Mozilla SpiderMonkey Javascript engine, as well as basic CSS support.
In theory that should make more of the Web accessible to it than the other text-based browsers. In practice we found there were few-to-no sites for which the JavaScript really worked. This seems to be due to lack of full DOM support. So while the JavaScript runs, it mostly just generates errors.
In spite of this, compatibility is surprisingly good. I tested a range of sites, including the Sailfish OS Forum, DuckDuckGo, Google, Medium, Wikipedia, BBC News, Ars Technica and The Verge. Getting to the content sometimes requires a bit of scrolling, but I was nevertheless able to navigate all of these sites, use their form-based features and read the articles on them. In most cases it was even what I’d call a “good” experience with adverts and images removed. At the other end of the scale, highly dynamic sites like Twitter, YouTube and Mastodon failed to work at all, showing just a “You need JavaScript” banner.
Perhaps the main reason why some users may prefer elinks to the others described here is that it has the most desktop-like user interface, including widespread use of dialogue boxes and menus. For example, pressing ESCAPE brings up the top menu with File, View, Link, Tools, Setup and Help entries, each with their own submenu navigable using the cursor keys. The ncurses library is used to manage all of this, which works very well and looks pretty clean using either Fingerterm or ToeTerm on Sailfish OS (for best results I’d strongly recommend activating the ‘Color mode’ in the Terminal options).
Navigating around pages is achieved using the cursor keys: the up and down keys jump between links on a page, right will follow a link while left will take you back through the browser history. That all feels pretty intuitive and most sites can be negotiated quite seamlessly this way. If you don’t want to jump between links, Ctrl-f (or SPACE) and Ctrl-b will jump a page forward and back, while Ctrl-n and Ctrl-p will scroll you down and up the page two lines at a time.
As you’d expect, most of the functionality is exposed through keyboard shortcuts. Press g to go to a URL, h to open the history and / to search in the page. Browser tabs are functional and easy to manage, stacking sideways along the bottom of the screen. Pressing T on a link will open it in a new tab, pressing c will close a tab, while the < and > keys can be used to swiftly switch between tabs. It’s all super straighforward and responsive, even compared to modern desktop browsers.
Another nice touch is that with just a little hacking of the ~/.elinks/elinks.conf file elinks can be configured to trigger image opening in the Gallery app using the v key (to get this to work, you’ll need to set the image_viewer program to "xdg-open %" and add relevant mime triggers like this: set mime.type.image.png = "image_viewer"). So if you really do want to view an image, you still can.
One thing to bear in mind for all of these browsers is that the keyboard shortcuts are usually case-sensitive, so for example while d will allow you to download and save the current link, D will open the downloads manager instead.
User interface aside, one of the most noticeable differences between elinks and the other text browsers is its support for CSS. The support is fairly basic, but it does nevertheless have an impact. For example, like (I suspect) many Sailfish OS users I have my terminal configured with white text on a black background. Both lynx and w3m will steadfastly conform to this colour scheme, while on many sites elinks will follow the CSS rules of a site instead, inverting the colours to display black text on a white background. I’m not convinced this is a good thing. Sure, it’s a fairer representation of the original site, but for just reading the text of the site, it feels like an unecessary distraction.
The last stable elinks release was 0.11 in 2009, but the version on Chum is the latest development version from July 2017. As far as I can tell from the git history there hasn’t been any public development activity on it since then (although there is a more active unofficial fork). As a result, OpenBSD have cited some security concerns. Notwithstanding this, elinks is certainly the most capable and least text-oriented of the three browsers here.
lynx
Amongst the text browsers we’re considering here, lynx is probably the most well-known and popular of the three. It has a long and illustrious history, having been originally released back in 1992, and it’s the only one of the three we’re considering today that is still in active development, an obvious and significant benefit. The release cycles aren’t exactly rapid with the last stable release (2.8.8) having come out in 2014. Nevertheless the development release — which is the version on Chum — is more up-to-date, having incorporated regular patches every couple of months since then.
With the default build it will support most static HTML features including forms, tables, and frames. It also supports UTF-8, cookies, text colours and SSL, but unlike elinks it doesn’t support CSS or JavaScript. As with the others here, it doesn’t support images either. Given the lack of JavaScript in particular, you might think it’s going to have a hard time on the modern Web. Well, it does, but not to the extent I had expected.
In practice it achieves very similar results to elinks. The Sailfish OS Forum, DuckDuckGo, Google, Medium, Wikipedia, BBC News, Ars Technica and The Verge all work well as long as your focus is the text of the articles. Twitter, YouTube and Mastodon all hit the JavaScript buffers.
Navigation is also similar to elinks, with the cursor keys used to move between links on a page, to select a link and to go back through the site history. Hitting Ctrl-f (or SPACE) and Ctrl-b will jump forwards or backwards one screen at a time, while Ctrl-n and Ctrl-p will move down and up the page two lines at a time. The fact the two browsers share a common approach here is quite convenient if you plan to switch between them.
You can also use g to open a new URL, / to search, d to download a link and o to open the options.
There are some differences though. The h key is reserved for the help text, which means Ctrl-h is used to open the history instead. Moreover lynx doesn’t support browser tabs, which many users are likely to miss.
While lynx doesn’t support images, it does have ways to tackle them. Hitting * will toggle between hiding inline images or showing them as links you can select. After adding a VIEWER:image/*:xdg-open %s line to the lynx.cfg file, selecting an image link will then throw it out to the Gallery app. It’s nice that you can switch between hiding and showing image links with one keypress, although it does trigger a page reload.
The overall user interface is minimal, allowing you to focus on the content. A status line at the top shows your position in the page, while a status line at the bottom provides useful hints, for example indicating what type of item (e.g. link, form item, etc.) the cursor is currently hovering over. It’s all very clear and succinct.
If you’re looking for a balanced experience between a full-on browser, and something simpler, then Lynx is a good place to start. Some may find the lack of tabs too restrictive, but if you’re big on link-navigation without the bells and whistles of elinks, then lynx will make for a good choice.
w3m
The w3m browser doesn’t call itself a browser at all, but rather a pager that happens to support HTML. But in practice that’s understating its capabilities, for while it is a pager (like more or less) it will also happily download pages from the Web using HTTP or HTTPS, aside from viewing local files.
The fact that it’s a pager rather than a browser only really affects the experience in so far as the keys used to navigate around pages are similar to those you’re likely to have experienced with other pagers. Being a vim user myself, this is something I particularly appreciated, with the same hjkl keys to move around that vim users will be familiar with (don’t worry if you’re not: cursor keys work as well!). There are also other familiar shortcuts such as g and G to move to the top and bottom, and \ to search.
Unlike elinks and lynx which jump between links, navigation in w3m using the direction keys is character based. This feels natural, but navigating large pages this way can be slow. Thankfully you can also use TAB and Shift-TAB to move to the next and previous links respectively, then use ENTER to select the link, which gives you the best of both worlds. Other handy shortcuts include SPACE to jump forwards a screen of text, b to jump back a screen, B to go back to the previous page in the history, s to open the history, U to enter a URL and q to exit.
Given how lightweight w3c purports to be, I was suprised to discover it has good support for browser tabs. Create a new tab by pressing T (if you’re hovering over a link it will open it in the background), close a tab with Ctrl-q, and switch between them using { and }. It all works surprisingly well, even using the confined keyboard of Fingterterm or Toeterm.
The downside of it being a pager is that it has a completely minimal user interface, to the extent that it requires you to enter a URL on the command line before it will even start to browse. Beyond that, you get a status line for tabs at the top, and a line for text entry at the bottom. Very slimline.
Whether this minimal user interface is a good or bad thing will fall to personal preference. Personally I love it, taking away everything except the page contents is exactly what I like. But it’s not for everyone and certainly steepens the learning curve.
What about compatibility on the modern Web? Like lynx, w3m does a good job of covering the basic static HTML tags: forms, tables, iframes and the like. It can handle colours, SSL and cookies. But also like lynx it skips CSS, images and JavaScript. On most sites the lack of CSS and images won’t affect the core textual content, but the missing JavaScript can be more of an issue. As you might expect, it struggled with more dynamic sites. Nevertheless, I was still surprised at how well it managed to navigate the Web, giving similar results as the others. The Sailfish OS Forum, which uses the Discourse platform, worked nicely, as did DuckDuckGo, Google, Medium, Wikpedia, BBC News, Ars Technica and the Verge. Sites it isn’t able to handle include Twitter, Mastodon and (unsurprisingly) YouTube.
One particularly nice feature is that w3m can be configured to open the Sailfish Browser with the current site if you press the M character, so if a site isn’t working, you can easily outsource it. Just add extbrowser "xdg-open" to the ~/.w3m/config file to activate the feature. Like the other browsers here you can persuade w3m to show images in the Gallery app too, but it requires some shenanigans to get around the Gallery’s sandboxing. You’ll need to create a ~/.w3m/mailcap file and add the line image/*; mv %s /tmp/w3mimage && xdg-open /tmp/w3mimage to it. Now, pressing I when the cursor is over an inline image will open it in the gallery.
Although w3m is arguably the simplest of the three, this made it no less effective for browsing the Web, and in the context of a text based browser, I consider this to be a positive. If you’re going to strip your browser back to the bones, you may as well go all the way.
Do I really need a text-based browser?
None of these browsers offer a classic Sailfish OS experience, and quite a few sites — specifically those which rely heavily on JavaScript — simply won’t function with them correctly. The Sailfish Browser already offers excellent capabilities and a great interface, so is it really worth considering one of these text-based browsers?
You won’t be surprised to hear that the answer depends on your needs. Most people can probably go through life quite happily without ever even knowing they exist. But there are reasons to like — maybe even love — a bit of text-based browsing.
One reason is context switching. You can use a text-browser in Fingerterm and ToeTerm sure, but they do benefit from a hardware keyboard. If you’re a Gemini or F(x)tec Pro user then this may highten their appeal. But even on a keyboard-less smartphone, they can be super-useful when you’re running an SSH session to your phone and just need to quickly download something to it. The context switch in doing this is likely to be far lower than moving from keyboard to the touchscreen of your phone.
In many situations, a text-based browser may also be more than enough. If you’re a frequent user of Reader Mode, you’re likely to appreciate the simplicity and clarity of a text-based browser. Not for everything, but when there’s a lot of text involved.
Finally, it’s hard to avoid the fact that for some people the monospaced text and 4-bit-RGB colouring is going to be nostalgically reminiscent of Teletext or Minitel (even if they were actually 3-bit RGB). Several people commented on this while I was testing out the three apps here, so there must be something in it.
Whatever your reasons, from nostalgia to tightening up your development workflow, there’s a certain joy to be had in cutting the Web right down to the basics. As long as you don’t expect any of these to replace the Sailfish Browser.
Repository roundup
The network stack
-
connectionagent, a daemon and QML bindings to connect to ConnMan, abranson modified the DBus interface so Wifi tethering and Bluetooth tethering can be manipulated separately. Previous, the tethering API was implicitely dealing with Wifi thethering only. The pull request has not been accepted yet.
Sound stack
-
amber-mpris, QML bindings for remote control of music players, tomin1 added support over DBus to expose non-hidden properties.
Calendar stack
-
mkcal, storage backend using SQLite for calendar entries, dcaliste’s patch to add a search method through out the database has been merged. A (very) minor optimisation was proposed by dcaliste and accepted. It avoids to poke the database for an event that is already in memory. Additionnaly, dcaliste proposes to clean the code out of::Ptrtype in the internal class handling read/write access to the database. It avoids to pin the data ownership to the current thread. -
nemo-qml-plugin-calendar, the QML for calendar access, dcaliste added a list model to display search results from the calendar database.
Synchronisation framework
-
buteo-sync-plugin-caldav, the synchronisation framework plugin for CalDAV content, dcaliste fixed an issue when importing exception. Imported events didn’t inherit the sync property like when creating an exception on device, confusing the sync plugin which was cancelling the import on the next sync round.
System control
-
sensorfw, sensor framework, spiiroin added fix for deadlocking state on exit due to pending interactions withlibgbinder. spiiroin also completed a large work on changing how refresh frequencies can be set-up. Indeed, rates of sensors depend on the device and the old API was quite restrictive because defined with integer millisecond periods, making not possible to choose a frequency of 400 Hz for instance (period would have been 2.5 milliseconds). spiiroin modified also the granularity for accelerometers, previously stored as milliG integers, now moved to single precision floating point numbers. -
qtsensors, Qt bindings for the sensor framework, spiiroin ported his work on allowing more fine grained frequencies in sensor refreshing to the bindings. -
ssu, the seamless software updater, keto fixed a bug where system CA certificates are not loaded.
Low level libraries
-
sdl, a multimedia library, mlehtima is working in a branch on upgrading to the latest upstream version 2.26.4. -
firejail, the isolation mechanism for process from the host system, dsuni updated it to 0.9.72. -
ngfd, the non graphical feedback daemon handling sound and vibration feedback, neochapay is suspecting a double free in the plugin forffmemless(i.e. the vibration driver). The pull request is discussed with pvuorela and monich. -
nemo-qml-plugin-dbus, the QML bindings for DBus, attah’s work adding support for array of string-variant key-value pairs, has been merged. This data type is used in the standard FreeDesktop DBus methods for launching applications, so it enables apps to call those methods from QML. It has been branched also inupgrade-4.5.0, meaning that it will be available in a possible next hotfix release. -
lvm2, userland logical volume management tools, mal is working on an update to 2.03.20.
SDK and developer tools
-
sailfish-secrets, a framework to use encryption techniques, sledges updated the documentation to point to the right IRC channels (they were still the ones used on Freenode). -
openssl, utilities and library for cryptography, direc85 contributed to the packaging, allowing to wipe out the warnings from rpmlint and to build succesfully withsfdk.
Sailfish OS website
-
jovirkku updated the release table with the 4.5.0.19 and added all minor releases, see Releases | Sailfish OS Documentation
-
jpwalden created two pages describing how to setup a freshly flashed device with Sailfish OS, see Setting up a Sailfish phone | Sailfish OS Documentation and Setting up a Sailfish phone part 2 | Sailfish OS Documentation
-
vigejolla complemented the synchronisation documentation with a description of Buteo profiles, used to define synchronisation schedule for instance, see Synchronization | Sailfish OS Documentation
-
jovirkku added an article describing how to use mapping services, taking among others PureMaps as an example, see Maps and Location service | Sailfish OS Documentation
-
jpwalden created an article describing the phone application, see Phone | Sailfish OS Documentation . He also added one for the document application, see Documents | Sailfish OS Documentation and for the calculator application, see Calculator | Sailfish OS Documentation
-
vigejolla added a reference description of the backup system, see Backup Accounts | Sailfish OS Documentation
Feed us your news!
Thank you for reading this far! We need your support in creating this newsletter - please write your topic suggestions in the comments below. And if you would like to write an article yourself, don’t hesitate to contact!
5G is a good feature, looking forward too for future ports! Hope to see some improvements over Sailfish Default Browser, like a new base of ESR of firefox. Hope 4.5.0.x new version is coming soon, like for April