News and Update
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.
Dalton commented that 16.04 still has its uses as a test platform for apps, even though it is not suitable as a user platform. Dalton intends to write more on that subject soon. Developing that idea could be useful to developers who are thinking of making UI changes. We are skipping 18:04 so don’t use that but 20.04 packages are coming. Thank you to Rachanan for the work he is doing on that.
There were more questions about the PinePhone, especially about needed kernel changes. This work has been impacted by the limits on our resources but it is firmly in the queue.
Sailfish OS plugins
Desktop Lomiri preference
Sponsors were thanked.
We are aiming for 100% test/diagnostic coverage of installer operations. It is all written in java-script. Getting involved in further development of the installer is a fantastic educational opportunity for developers because it covers so many bases. Writing test routines once you have got to grips with the underlying code is a great way to learn! Nodejs Electron is a very nice, readable application.
For those who hadn’t noticed yet, the installer is now able to unlock the bootloader of some devices automatically, in fastboot mode.
Marius playing over holidays and Qt upgrades
Another strand towards 20.04 is the Qt 5.12 upgrade. Lomiri is not yet in the Xenial archive. Every time we upgrade our Qt version it gets faster, as there is a huge amount of optimization going on. Our problem is that our testing regime takes finite amounts of time and each element runs so much faster that our tests now bump into each other. Of course we can just introduce wild loops to slow it down for testing… Dalton showed a test rig of Lomiri running in Xforwarded mode, without Mir, all on its own. Doing that in segments can help easily identify where things are going wrong.
It should already be possible to start rebuilding your apps again, to account for the Qt upgrade. Crossbuilder is probably still a problem but you should be okay with Clickable. Apologies that this process has taken so long but it turned out to be more challenging than it appeared.
Qt 5.15 will be a wait. We really need to reach 20.04 before we start to implement that.
Coming up (hopefully in this first half of the year) will be the work on the 20.04 upgrade. That is now our top priority. It is unlikely that we will see an overnight switch of everything from 16.04. We expect a transition to allow people to catch up, so don’t panic. Also, don’t panic about the security aspects of this being late in the LTS cycle. There are upstream changes which address weaknesses in 16.04 but more than 90% involve packages which we don’t even use in UT. Remember that our sandboxing architecture provides an additional layer of security, making irrelevant many of the risks that affect the desktop OS.We will not have everything done in April, so we will breach the LTS cycle. That isn’t a major concern though and we don’t expect much of a gap.
On the Mir and Wayland front
There are currently two versions of Mir – 1.x and 2.x. We are still on 1.x, which supports the old mirclient and Mir server (which is an API type thing). 2.0 has unpublished Mir server and mirclient. Not everything in API terms is in Miral or has been moved over, so Alan has made something called Miroil, which will provide the missing features. It will provide the bare minimum for Qtmir to work. Fortunately there are only two components that still rely on Mir server – Qtmir and Lomiri System Compositor. A new compositor is being worked on and there should be no problem with that. Qtmir is the difficult one and will require Miroil to run, for some time.We want to move the hybris devices over to Wayland at some point but they are working okay at the moment so there is no big pressure for that. Mir on hybris will probably stay on 1.x for a little longer. PinePhone and desktop are likely to get 2.x sooner.
As mentioned above, there is a project to develop our indicators so they can be run on other than UT. We will be shifting their namespaces to reflect that. MATE is interested. Indicators are quite strange things so by expanding their user base we hope to gain more involvement in tidying them up, streamlining the building process and improving localisations. Every indicator has a different library and a different language. They really are a mess. Manjaro are using our indicators already, in our joint Lomiri project and actually they work great despite being so diverse.
UI changes ideas
There was a lot of comment in the live chat about ideas for major UI changes in UT. As with comment in our messenger groups, those get quickly lost and need to be raised in a more permanent form, in a structured discussion. We have a forum for subject debates and urge people with concrete ideas to create mock-ups to illustrate them, then post those on the UBports forum. We have no interest in looking ‘more like iOS’ or ‘more like Android’. We are not them. We haven’t made huge changes to UT visually since Canonical days but bear in mind that they brought substantial professional expertise to bear when deciding on their design.
Broadly, we see no reason not to trust that they knew what they were doing. It may be a little dated perhaps but at least it is professional and we don’t have access to similar expert resources. Our UI has a lot of fluidity in use and that is a characteristic feature that we don’t want to lose. As we evolve the UI, we want to build on that, not scrap it. Persist with it for a while. Most users find Android perplexing and frustrating after using UT.
See you next time :-)