Ubuntu Touch Support

[r0kk3rz]

I have started (but not tested) some Ubuntu Touch Universal Components:
https://github.com/r0kk3rz/universal-components/tree/master/ubuntu/UC

Would be great if a Ubuntu Touch developer could test these out, or if @M4rtinK would be happy to pull these without testing being done

[M4rtinK]

I have started (but not tested) some Ubuntu Touch Universal Components:
https://github.com/r0kk3rz/universal-components/tree/master/ubuntu/UC

Looks good. :)

Would be great if a Ubuntu Touch developer could test these out, or if @M4rtinK would be happy to pull these without testing being done

Certainly would be good if someone with an Ubuntu Touch device (or is there also a UT simulator ?) took a look and checked how the components actually look like (I don't have a Ut device at the moment), but I am open to merging them even without that if no one shows up - the Ubuntu components can always be marked "experimental" for the time being.

BTW, I'm thinking that a simple example application might be useful for checking how Universal Components look like on different platforms.

[M4rtinK]

BTW, I have pinged Mike Sheldon:

https://twitter.com/M4rtinK/status/692818694997676033

He is a developer working on Ubuntu Touch who has done a proof of concept of modRana running on Ubuntu Touch (via the Controls backend) in the past.

[r0kk3rz]

My thoughts were along the lines of "if someone tries to use it and finds it broken, they might help fix"

@davidar has been using some in his Tensor app here: https://github.com/davidar/tensor

[Elleo]

Had a quick glance at it, from a Ubuntu Touch perspective the only thing I'd suggest is switching to "Ubuntu.Components 1.3" (at the moment you have a mix of 1.1 and 1.0), as this is the latest version and has some speed benefits, new features, etc. A quick test with a few of the components ran fine :)

I don't know how well it lines up with the UC API, since at the moment it mostly just translates directly at the component level, I'm not sure what property names UC guarantees (is there a listing of this anywhere?), so I don't know if there's any extra aliases or anything that'd need setting up to maintain full compatibility?

[r0kk3rz]

It doesnt cover the full list of UC objects, I mostly just picked the low hanging fruit that look like they should wrap in without any additional work to get something started.

You're right, it would help if we had a proper UC API which things would need to adhere to, maybe using QtQuick.Controls as a main guide just to try and keep things standardish.

[M4rtinK]

Had a quick glance at it, from a Ubuntu Touch perspective the only thing I'd suggest is switching to "Ubuntu.Components 1.3" (at the moment you have a mix of 1.1 and 1.0), as this is the latest version and has some speed benefits, new features, etc.

Certainly good to know - thanks! :)

A quick test with a few of the components ran fine :)

Nice!

I don't know how well it lines up with the UC API, since at the moment it mostly just translates directly at the component level, I'm not sure what property names UC guarantees (is there a listing of this anywhere?), so I don't know if there's any extra aliases or anything that'd need setting up to maintain full compatibility?

This is a good question - well, the top level API is the component names itself, mostly due to the inflexible import declaration in QML, that does not support conditional imports. The de-facto listing of this is the qmldir file of a complete implementation, so for example:

https://github.com/M4rtinK/universal-components/blob/master/controls/UC/qmldir

As for the available properties of the individual elements - that's indeed something that is not formally defined at the moment, partially as unlike the imports, applications can potential handle missing or different element properties at runtime. Another reason is that so far the available properties have been driven by what I have needed for implementing the cross platform modRana QtQuick 2 GUI.

Generally if the properties were named differently I have chosen one of the names an created an alias named after in in the other backend so that no application side code is needed to handle this. In case the apis differed greatly, such as with the combo box implementation in Controls vs Silica I selected one implementation (the Controls one in this case as it look the most robust & portable) and made a compatibility layer for the other (Silica). There might even be a case where UC adds its own common property that translates to dissimilar properties in the backends.

Anyway, it is a very good idea to make a listing of the "API" UC provides - both a central listing of "official" element names and then a listing of common API the elements should have. That should cover both common API, which is currently kinda invisible - if both Controls and Silica version of the component have a "name" property, you just would not see it anywhere in UC at the moment, creating a potential issue for creators of new backends and the compatibility APIs provided by UC.

;tl, dr: I'l try to write an UC API spec over the weekend. :)

[M4rtinK]

You're right, it would help if we had a proper UC API which things would need to adhere to, maybe using QtQuick.Controls as a main guide just to try and keep things standardish.

Yeah, Controls can be a good guide for the overall common API as IMHO it is kinda the most mature of the different component sets & many sets use them already as backend thus making our work easier. :)

Still there could be cases where another set provides some nice property that can be easily supported on controls and other sets or when a property can be created by UC that cover a range of component sets better than just grabbing an existing property.

But generally following the Controls API as a guide should work in most case. :)

[M4rtinK]

BTW, looks like @davidar, the author of tensor, already did some work on Ubuntu Components based UC backend:

davidar@65045af

I guess it might make sense to ask him join the effort or at least use some of the components he added ?

[davidar]

@M4rtinK sure, I'm happy for my changes to be pushed upstream

[r0kk3rz]

yeah I grabbed the ubuntu components in my fork as well, but good to attribute proper author.

Theres also some mods to the silica components too you might want to look at

[M4rtinK]

@M4rtinK sure, I'm happy for my changes to be pushed upstream

Nice - thanks! :)

yeah I grabbed the ubuntu components in my fork as well, but good to attribute proper author.

Theres also some mods to the silica components too you might want to look at

Sure, I'll take a look once I have some time. :)

[M4rtinK]

@Elleo @r0kk3rz I've finished writing the Universal Components API spec:

https://github.com/M4rtinK/universal-components/blob/master/docs/api_spec.rst

Let me know if you spot any mistakes & feel free to improve & extend. :)