• About
• Latest Posts

Purism

Beautiful, Secure, Privacy-Respecting Laptops, Tablets, PCs, and Phones

Latest posts by Purism (see all)

• PureOS Crimson Development Report: October 2024 - November 14, 2024
• PureOS Crimson Development Report: September 2024 - October 16, 2024
• Quantum Safe Communication with Purism - September 23, 2024

The Librem 5 is a big project. And like a lot of big projects, as you probably know, it can appear overwhelming, until you can break the parts down into logical steps. Like a large puzzle scattered on a table, our team has been organizing and beginning to assemble all the pieces. This is very exciting to progress through the initial daunting scope, accepting the tasks, start working and then… after some time, solutions emerge and almost magically align.

In our previous blog posts we described what we were starting to work on, and these efforts began to prove themselves out significantly during our week-long hackfest where part of our software phone team gathered last week in Siegen, Germany. In addition to myself, we therefore had Bob, Heather, Pedro, Dorota, Adrien, Guido, and Todd joining us.

Compositor and Shell

One of the most important parts of the phone user interface is the Wayland compositor and the UI “shell”. The compositor coordinates the drawing of surfaces, which basically are the different application windows, and the shell provides basic user interfaces for starting applications and e.g. control widgets like for connectivity, display brightness, rotation etc.

For a number of reasons—and after having evaluated several possible choices with upstream project maintainers (including GNOME Shell maintainers)—, we set out to develop a clean-slate Wayland-only compositor and shell based on Wlroots and Rootston. Guido is heavily working on this, and the results we’ve achieved within the short period of time are pretty amazing—it is the foundational work for the rest of the UI images below.

We now have a mostly complete compositor working on the i.MX 6 development boards working, based on Wlroots and Rootston, with a start of a small phone desktop shell (phosh) providing window handling, full-screening of application windows, a first start of controls menu also allowing runtime display rotation—so you can at runtime rotate the display to either landscape or portrait mode and running applications will automatically be resized to the new display geometry.

All of this is already running and working on the i.MX 6 board and proves to absolutely be performant enough to be usable for everything we need. This also proves that our approach indeed will work out. The shell component of it, Phosh, is still at a very early “proof of concept” stage but already allows launching some applications from it. The important part here is that all the infrastructure is in place to show such application chooser menus to exist and to launch applications from it. Now we can work on completing it and adhering to the designs that our design team has proposed.

Adaptive (“Responsive”) GTK+ Applications

One of the big challenges in writing graphical user interface applications is to design the UI in a way that it can be used on different screen sizes, geometries and resolutions. The phone is an extreme case of this because it has a very high resolution in a small form factor (about 5 inches) and is mostly used in portrait mode “but you can turn it into landscape mode” and you can connect it to an external larger screen… but you want to be able to use the same applications in all of these situations.

Therefore, graphical user interfaces need to adapt to their environment (window/screen size, orientation, resolution). We’ve seen this happen mainly in the website design industry in the last few years, what the industry calls “responsive” design.

Except we are officially calling it adaptive design, or adaptive applications. Not because we want to be fancy, but because “responsive” is a term that can have multiple meanings, and particularly, in the traditional software applications industry, can be interpreted as “performant”. A responsive application is something that reacts—or responds—swiftly to user interaction, and a non-responsive application is a hung up (or otherwise “not responding”) application.

At the moment most applications are not tailored for this kind of use case. So we looked into this issue and Adrien started to develop with a widget for GTK+ that could probably solve this problem—or at least make it a lot easier to create new adaptive applications and port existing ones to this new technology. The widget Adrien designed is an adaptive container widget allowing to automatically show or hide certain other widgets according to window size and geometry. As a proof of concept of how developers can simply modify an existing application to become adaptive, Adrien modified the GNOME Contacts application to use his new “responsive” box and this turns out to work quite nicely, as you can see in this rough video, again running on the i.MX 6 board:

The contacts application is a pretty simple application, at least concerning its user interface. As a next step Adrien will be testing the adaptive/responsive widget on an email client, stay tuned!

Input methods

Besides the compositor, shell, and UI layout, one of the most critical parts of a mobile device software suite is input method handling. Pushing buttons and reading text is one thing but you also want to be able to input text, and this requires a pretty complex row of software components talking to each other, involving namely the compositor and the toolkit used to develop the application. Dorota has worked on this and connected the necessary protocols and plugins, and now has a working input prototype based on the Wayland input method protocols, the Weston virtual keyboard, a GTK plugin and a sample application receiving the text in an input widget:

You can see text being typed in on the virtual keyboard and showing up in the test application. While doing this Dorota also came up with the necessary methods to show and hide an input method depending of the input widget focus, etc. The same should have also been working with Qt applications already but it did not, and so Dorota is working on getting this to work. We are confident that we can soon also support Qt applications with this input method.

The protocol used for the input methods is not bound to the Weston virtual keyboard, i.e. it can be applied to other input methods and makes developing or adapting such input methods much easier.

Telephony

Last time we presented a first SMS being actually sent from our development board through the modem to some other mobile device, and we promised to work on phone calls next. Bob did a lot of research in this respect and we are beginning to understand the inner workings of oFono and Telepathy ring a lot better. We are still not completely there yet, but are starting to fill-in how it can all be done. The nice thing about researching and taking the time to fully understand the interfaces and this code is that it will allow us to very easily plug this into a dialer application and have the call establishment working.

Documentation, SDK

Now that the software stack becomes clearer it is very important to keep track of collected knowledge and to document this. Over the past weeks Heather has started this effort. She is not only documenting existing developmental efforts, but also integrating the products of the developers into what will become an emulator and SDK for new developers. We want to provide an integrated development experience for new developers that—in some not too distant future—shall enable development for all Purism devices, be it the laptops or the phone. We also aim at being open to different programming technologies, be it languages such as C, C++ or Python, and toolkits such as Qt or GTK+. We are of course aware that this will not work 100% “from day one” but this is our goal, and we are laying the foundation for an inclusive development approach. Heather is currently working with GNOME builder since it support a wide variety of programming languages and toolkits and it has the built-in ability to create Flatpak packages. She is also working on easy test deployment strategies so that developers can directly deploy an application from Builder either into a virtual machine emulator for the Librem 5 or directly onto a connected development kit or phone device or into a Flatpak package that can be shared.

This work is of course especially useful for our development kit users that will receive the development boards in June. Before that time we will launch a complete new website dedicated to development for PureOS and the Librem 5 phone.

Hardware

While our hardware team were not able to make it to Siegen, we did receive our first i.MX 8M evaluation kits last week and have begun evaluating these along with the software and drivers. We also will be evaluating a promising source for manufacturing and will be getting a factory tour from mid to end of March.

The pieces are coming together

A lot of pieces of our huge puzzle are snapping into place and these emerging shapes are starting to take proper form. We have a basis for the UI (compositor, shell), we have a proven way to adapt applications to the challenges of different screens (responsive box), we can input text to applications, the telephony stack becomes clearer and we have an approach for upcoming PureOS phone application developers.

We are extremely excited about the progress that we were able to make in such a comparably short amount of time. Stay tuned, a lot more things are coming…