June 1, 2017 App Developer / OS Developer Meeting

UniSuperBox

This is going to be a wall of text, but I'm sure that's okay for everyone.

Today we had a meeting to discuss the future of the Ubuntu Touch platform as it pertains to app developers. We brought in real, live app developers to help with this (thanks everyone for taking time out of your day!). We got a lot discussed and finished, and have a few topics to discuss further.

The following are my notes from the meeting, only edited for formatting or clarity. Actionable points are marked with [A] and what's in them will be added to a to-do list or the community will be asked for help with them.

If you have any questions or comments pertaining to the formatting or language of these notes, please reply here. If you have anything pertaining to the content of the notes, please create a new thread in the App Development forum. This lets discussion happen in a more on-topic manner.

Are we using Snaps?

We'll get them either way by upgrading to Xenial, but are they the best for us?

Tabled for later because of next point.

Changes to snapd needed?

[A] Add content hub, notifications, a few other things in upstream. Canonical will probably be accepting of these changes.

How should we handle breaking compatibility?

There will be binary incompatibilities between 15.04 and 16.04 due to gcc changes. There is no way around that.

See if we can compile two versions of an app for each platform.

[A] Maybe we can use a chroot to run the old stuff to run old apps.

ContentHub

[A] Add (or merge) Mimetype support

[A] Add file picker

Confinement

Needs a few more features, like the SD card access for apps

[A] "Access to sd card could happen with the same rules used for user's folder. i.e. /media/*/apps/<App_id>/{config|data|cache}"

Notifications

Lots of discussion.
[A] Arrived at calling an app in the background to do its work. Ubuntu will call apps with a certain argument to put them into background mode.
The app must finish its work in under x seconds and use under x CPU, or be blacklisted
Provide options to the user to deny this permission to some apps or (maybe) change how much battery an app is allowed to take.

The Platform

Qt

Lots of discussion about Qt 5.9 vs 5.6. No decision made yet. Tabled for another meeting and decisions by upstream.
QtQuick2 is a good reason to hit 5.9
Create a forum post about this (coming soon). 5.9 might provide more portability between platforms for devs.

Edit: After discussing a bit with @jsalatas and rereading messages from @bshah, I found that this discussion had a grave flaw. Namely, Plasma isn't working on 5.9 yet, but 5.7. It turns out that Yunit compiles under 5.7 as well. More discussion of this point is still needed, but I thought this was a big enough issue to warrant a strikethrough.

Making the UITK a QtQuick style would provide even more portability.

Other

[A] Ship pyotherside in the image so devs don't need to ship it themselves.

Don't remove bacon2d.

[A] Maybe remove the circle on the lockscreen and libusermetrics

[A] QtWebEngine: Talk with Sailfish on the web engine they're going to choose. QtWebEngine doesn't compile for ARM yet. Any changes from Oxide would require a lot of changes to mediahub.

[A] u1db can be removed and replaced. It's mostly been replaced in the core apps.

Ask ommitted about the Ubuntu Storage Framework. It might be useful in the future to maintain it. https://launchpad.net/storage-framework

Ubuntu Messaging Framework

All the chats in one app! The community isn't very excited about this and prefers multiple apps for multiple platforms.

Yunit Changes

Tabled for another meeting between UBports and Yunit: Qt changes, splitting dash and Yunit

Some discussion about removing scopes from the platform and providing a single place (like Today) where apps can display info if they want.

The Apps

[A] Dialer had VoIP support coming. We should continue this.

[A] Put an issue on all core apps that do not have a maintainer, asking for a maintainer.

A Former User

@UniSuperBox said in June 1, 2017 App Developer / OS Developer Meeting:

Edit: After discussing a bit with @jsalatas and rereading messages from @bshah, I found that this discussion had a grave flaw. Namely, Plasma isn't working on 5.9 yet, but 5.7. It turns out that Yunit compiles under 5.7 as well. More discussion of this point is still needed, but I thought this was a big enough issue to warrant a strikethrough.

I just had an extensive chat with @UniSuperBox. To be honest after that discussion I realized what you were trying to achieve

Anyway! Currently I confirm the whole Yunit stack can be built against qt 5.7.1. So the issue here is to backport the whole Yunit stack to ubuntu 16.04 which comes with qt 5.5 if I'm wrong. Right?

If this is the case, then I guess I could try to have it done for the desktop. Will that be in any help for you? I mean if I could provide you with a ppa with latest yunit compiled against qt 5.7 that runs on top of ubuntu 16.04, would that be enough for you?

Bastos

@UniSuperBox said in June 1, 2017 App Developer / OS Developer Meeting:

[A] Maybe remove the circle on the lockscreen and libusermetrics

I personally like the circle very much at least after having understood its meaning and functionality. Would not remove it but maybe enhance logscreen info functionality.

Locamama

FRENCH
Tout à fait d'accord avec Bastos, peut être rajouter les chiffres pour donner un sans au cercle

ENGLISH
Strongly agree with Bastos, can be add the numbers to give a without to circle

sverzegnassi

@jsalatas Can I presume that you're working on Debian Sid then?

Well, the discussion we had was originally aimed to move our stack on Qt 5.9, which includes performance improvements, long-term support and QtQuick Controls 2.

We've got a lot of afterthoughts, this is our current situation:

Vivid+Overlay: Qt 5.4
Xenial: Qt 5.5
Xenial+Overlay: Qt 5.6 (LTS)

While Qt 5.6 would be anyway an acceptable compromise (the whole platform has been already tested by Canonical on 5.6 iirc), we realized that we can't anyway use the Canonical Overlay PPA for Xenial, because no-one is going to maintain it.

Qt 5.5 would probably be a too reductive solution of us, so (I guess) we've found anyway an agreement on maintaing a newer version.

The possible choices we've found by far:

Using Qt packages built by Plasma Mobile (5.7) or KDE Neon
Building and maintaining packages for Qt 5.6 LTS by our own
Building and maintaining packages for Qt 5.9 LTS by our own
(others ?)

We got interrupted here, as we needed to have more info from you.

Having QtQuick Controls 2 would be a great thing, as:

We could stop maintaining Ubuntu UI Toolkit, which is quite huge
We could just provide a QML skin for QtQuick Controls components, which are heavily optimized (written on C++)
We would gain support for the Hi-DPI support provided by Qt itself (which mostly work as the well-known GRID_UNIT_PX), with the plus of supporting different values on different screens (this is actually broken in UITK iirc)
We could gain more appeal and interest from using standard components

I'm clearly pushing arguments for moving to Qt 5.9, since I think it would be a perfect fit for our UBports goal.

However we still need to consider yunit needs, and possibilities we could have e.g. collaborating with Plasma Mobile, etc.

sverzegnassi

@Bastos Arguments for proposing the removal of the user metrics were about standardizing our development libraries, and matching latest (and probably unreleased) UX specs written by the Canonical Design team.

Lockscreen concept

Note: UX team used to mix different versions of UI components in mockups.
Although the black status bar uses the old design, this is about the latest specs available - reviewed in March 2015.

EDIT:
I had a further look on this.
I found out that 27 QML apps (out of 1054) actually use user metrics. It's about ~2.56%.
All the apps in the store (including webapps, which doesn't support UM) are 2579, so the percentage is ~1.04%

However it's still worth to note that those 27 represent some of most used, high quality applications, therefore it could still be worth to think at a different place where to put those data (e.g. Today scope?)

A Former User

@sverzegnassi said in June 1, 2017 App Developer / OS Developer Meeting:

@jsalatas Can I presume that you're working on Debian Sid then?

Yes. that is correct! I have already a working desktop in sid (using qt 5.7)

@sverzegnassi said in June 1, 2017 App Developer / OS Developer Meeting:

Using Qt packages built by Plasma Mobile (5.7) or KDE Neon

I would suggest this for now. Given that we want to run it on top of 16.04 and given that KDE Neon already has 5.7 packages that are running on top of 16.04, I believe this is the safest path to follow.

In fact, I already proposed that I could try to backport the desktop part to 16.04 if that will be of any help to you.
Please confirm!

@sverzegnassi said in June 1, 2017 App Developer / OS Developer Meeting:

Having QtQuick Controls 2 would be a great thing, as:
We could stop maintaining Ubuntu UI Toolkit, which is quite huge

Are we talking about this https://launchpad.net/ubuntu-ui-toolkit ?
If so then, it is still a dependency for yunit.

To recap: my opinion is that we should go one step at a time. I would suggest that the first step should be to backport the code I currently have (from ubuntu 17.04) to 16.04 and I believe I can have it pretty soon for the desktop part if that would be of any help to you.
Qt 5.9 is a no go from my part, as we don't have yet a CI infrastructure so we eventually cannot touch any code, yet $:\$

sverzegnassi

@jsalatas If we have some shared agreement on this, we can use Qt5.7 at the moment.

This version still provides QtQuick Controls 2 (although some component is missing), so we would have anyway some base for working on new stuff.

My biggest concern is who's going to maintain UITK - we can consider it stable enough, although UITK devs were planning a huge rewrite for v2.0[1] (performance issues and bugs, mainly)

[1] I'd like to provide a link to their blog post, but Canonical decided to wipe any post about Ubuntu for phones from developers.ubuntu.com (and no archive on Wayback Machine)

A Former User

@sverzegnassi said in June 1, 2017 App Developer / OS Developer Meeting:

My biggest concern is who's going to maintain UITK - we can consider it stable enough, although UITK devs were planning a huge rewrite for v2.0[1] (performance issues and bugs, mainly)

Well.... I guess yunit should maintain it as it is a build dependency $:\$

In any case yunit should maintain it until it is not needed any more

flohack

@sverzegnassi @jsalatas I agree lets aim for Qt 5.7 then, at least until we find out it doesn't work. We put this up for the next Q&A...

BR

A Former User

@Flohack said in June 1, 2017 App Developer / OS Developer Meeting:

@sverzegnassi @jsalatas I agree lets aim for Qt 5.7 then, at least until we find out it doesn't work. We put this up for the next Q&A...

BR

So. Should I make it a priority to have yunit compiled against Qt 5.7 on top of ubuntu 16.04? If I have a working set of deb (and deb-src) packages, can you take it from there, or do I need to do something else?

mardy

I asked in the #ubuntu-devel IRC channel, and was informed that some parts of Qt 5.9 are already in debian experimental: that includes qtbase and qtdeclarative, which AFAIK is pretty much what our applications are using. QtQuick Controls 2 is not yet there, but I guess it will come.
I've been told that mitya57 (on IRC) would happily accept any help in making Qt 5.9 available in Ubuntu, so if someone here has the time and the expertise to help, that would certainly give us a boost.

But in absence of that, I do agree that backporting to xenial the already packaged 5.7 is probably the most efficient way forward for the immediate time.

UniSuperBox

As just discussed, @jsalatas will try to build Yunit with Qt 5.9 and see what happens. This will bring a lot of performance improvements for ARM, native QtQuick2, and a few other extremely helpful features. We hope to hear back from the Yunit team soon.

Aurze

Also going for a LTS (5.9) release seems a good idea.