June 1, 2017 App Developer / OS Developer Meeting

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.