News and Update
Presenting this time around were Dalton, Florian and Alfred.
Stereopticon
Linuxafterdark podcast
Dalton gave a plug to his new podcast, entitled LinuxAfterDark.
A
big shoutout of gratitude to everyone who voted in the B1 Systems give-away. UBports secured second place and accordingly was awarded €1.400. Our congratulations to all the other winners.
OpenStore new apps
Another new app is Transmission remote. It allows you to check on the status of your torrents from anywhere in the world. It is a client/server hybrid, not just a client.
TotalSonic reported on the introduction of GemFork by Aaron Heffner. It updates the Gem browser, which is a Gemini gopher browser.
Multimaps is an app which uses satellite data to display data simultaneously from a variety of different map applications.
OTA-20 news
Most of the stuff will be under the hood but one very visible thing will be the ability to create and set a custom SMS receipt sound. It will also be available to any other app (such as Teleports) which delivers notifications. Thanks to LionelDbf for that. Vibrations and LED flashing is not 100% fixed but devices that are Android 9 and above should see this most of the time.
Florian has not only moved to a new address but his second son has been born, so if he has been a little less visible recently, that is why! Congratulations to Florian!
A reminder as ever that testing is a crucial part of preparation for a new release and there is nobody out there who is not capable of helping out with that [except of course those that don’t have a UT phone!]
Project 20.04 transition news
Guido has packaged up ofonoQt and Telepathyofono. These work together, with Telepathyofono grabbing messages from Messaging and putting them into ofono and historyservice. It takes calls and shows some notifications but not others. It is a huge module. It needs more testing but it built successfully and is in our 20.04 fork.
Rachanan has been working on a compatibility layer for apps which import e.g. ubuntu.components, substituting equivalent Lomiri components.That will greatly help app developers in making the shift from 16.04 to 20.04.
The Ayatana indicators in 0.9.0 version are nearing completion. Those will be upstream to UT when released. A third partner to this was Mate and soon all three will benefit from this upgrade.
A few months back Alfred got his PinePhone to run with 20.04 with mirclient support etc. He made some initial efforts towards getting trust prompts working with pulseaudio again. He has now put those tweaks up for preview. In addition, he has been talking to Rachanan about how maybe to get ADB support running for 20.04. The outline is there and it is a good first step.
Sponsors were thanked. Not all of the individual sponsors are identified to us (for example on Liberapay) but if anyone who has given would like a personal mention on air, just drop Dalton a message and it shall be done.
Questions
The News section of our Forum is the best place to post questions for the Q&A. YouTube live chat,Telegram and Matrix are other places to post a question.
If you didn't know, the Forum questions get priority.
Ubuntu Touch compatible devices
UBports installer
Testing environment
Device maintenance
Stanwood noted that around half of the UT compatible devices are marked as inactive, including PinePhone, Xperia X Performance, Xiaomi Redmi Note 7. Will it be a challenge to keep those served by OTA updates, if there are no longer maintainers? The changes to the Devices pages are a work in progress. There are some errors in there and information is incomplete. We are still trying to find the best way to present the facts to users. Feedback about the detail and the general approach is very welcome and can be added to the Gitlab page.
Putting all that documentation stuff to one side, there is still an important question. If a porter abandons a device, what happens then? This question is complicated by the journey to 20.04 which will become an effective block for some devices. Porting doesn’t end. A port must evolve in order to keep up. Updating all ports falls far outside what the core team can do, although individually they do cover a handful of devices. For anyone, two or three devices is the realistic limit. More than that and they will likely all collapse.
For any device which is unsupported, it doesn’t mean that it will immediately ‘switch off’. It will stay exactly as it is and continue to function.
Usernamespace should be set to ‘On’ in 20.04. That will necessitate a patch to the kernel of all devices [except PinePhone]. Some devices will then report ugly compile errors and in the worst cases crash at boot. We don’t have a definitive list yet of the devices which cannot be updated to 20.04 but as we discover blocks, maybe we should start such a list?
We know that Nexus 5, Oneplus One and Fairphone 2 fail the test of a readily up-gradable kernel. Fairphone 2 does however have kernel maintenance by both Lineage and Fairphone, so there is something to work with. In principle, anything can be done but our position is that if Dalton has to do more than 40 hours work trying to rescue 5.1 builds, they will be abandoned. Those are popular devices and they are still working quite well but please factor in that they have a finite life and if you possibly can, at least plan for their replacement ‘soon’.
It isn’t just those devices. The end of BQ, MX4 and Nexus 4 is pretty clear. On top of that, there are ports where we are just unable to reach the porter to find out their intentions. We have to assume at this point that they will be left behind. We can issue updates for those for a while yet and probably have no issues but a point will come where an update meets a bug and that device will reach a dead end.
This is really a new problem so we haven’t developed any protocol for handling it but with a lot of devices in the list and with many of those having shaky foundations, we need to start signalling our expectations and intentions more clearly.
Please port responsibly. If you put a port out there, be prepared to keep it going for a decent period of time. It isn’t a game. People spend hard earned cash to buy those devices. Don’t abandon them!
Camera access
Opaijavai asked whether the Camera app could be accessed from the lock-screen, to allow a quick photo without unlocking the phone? Lomiri has something that would enable that to happen. It is the same mechanism which works for the Phone app, which obviously has to work in that way. That part would be relatively straight forward but for that to happen, the Camera would have to be given awareness that it is open solely for the purpose of taking a photo, with no access to Gallery, controls etc. Again, it is possible to do but whoever took that on would have to understand that they were taking on a lot of work. The request for that facility has been around in Github for five or six years. If it was easy it would have been done a long time ago. It needs app suspension, lifestyle management and permissions. A great project for someone who wants to get their hands dirty with the inner workings of UT.
Core developers, what would you like to see on Ubuntu Touch!
TotalSonic commented that Q&A sessions tend to fill up with feature requests that users would like to see implemented sooner rather than later. Turning that around, what things would the core developers really like to see developers pick up and run with?
Alfred has been using a Mac as a development machine and he noted that Apple have a great feature, which it would be awesome for us to have too. That is Handoff. If you are in the middle of doing something on your phone, such as writing a document, when you open your Mac you will be asked if you would like to continue working on that document, using your laptop instead. Of course people here will naturally react with privacy concerns about this kind of merging of two devices but there are ways to do it which would be privacy respecting.
We have one part of the solution already with ‘convergence’. A UT app has the same capabilities on large screen or phone. The missing part is data sync primitives. Those would have to be quite sophisticated because it is not a case of ‘share all the data’. Only the relevant data should be shared and it needs to be accompanied by the context i.e. which app was handling the data and when was it being worked on? Apple do it by integrating iCloud with every part of the system. We would need a quite different approach. A single app could be adapted to provide something like this but it would end up being very bloated and we would not want to keep reinventing that wheel. The idea would be to have a system level capability that apps can simply plug into, with very little action needed by the app developer.
Making ContentHub more sophisticated at the same time would bring convergence and data convergence together, to create ‘convergence on steroids’. Canonical left behind the primitives and the ties to ContentHub, so an outline structure exists. Systemd does not help in the least as it is about keeping you data in one place, not keeping it in multiple places.
Florian pointed out that from a developer perspective, he doesn’t get particularly drawn to things that would be of major benefit to ordinary users because he spends his time firefighting rather than ‘using’. Nevertheless, there are some ‘ordinary’ things that he does think could be improved. One obvious area is the lack of optimization. We spend a lot of time getting things to work but we don’t then have the time to polish and refine so that it becomes slick. Alongside that of course is battery lifetime. The phone does things but it doesn’t do them in the most efficient way, so more energy is consumed than is necessary. Our energy saving routines are very weak, compared with Android or iOS. To sum up, we want to be able to manage things with a UT phone, not to manage the UT phone.
On top of that, the switch between using cellular data and using WiFi is disappointingly slow in UT. We need to get to a point where it is seamless and immediate. On that point, network-manager in 20.04 could have a beneficial impact but we will have to wait and see.
Dalton was speculating that if we took some features out and designed a very minimalist package, that would cut down on the amount of work involved. Marius corrected that by pointed out that it wouldn’t reduce the amount of work, it would just send it in a different direction. Slow technology and calm use can still be an objective in their own right but they don’t actually mean a reduction in the effort needed for development.
Dalton threw out there for discussion what community members think ought to be the nature of the future UT phone. He didn’t mean submit feature requests. Absolutely not that! But what could a phone be like if re-imagined? How could our relationship with the UT phone be re-imagined? This is about how tech could work differently but also how we change ourselves. Heavy philosophical stuff :)
A reminder. Please Port Responsibly!
See you next time :-)