Mobile components and convergence

[Aleix Pol]

On Wed, Mar 23, 2016 at 11:42 PM, Thomas Pfeiffer
<thomas.pfeiffer at kde.org> wrote:
> On Mittwoch, 23. März 2016 17:58:55 CET Sandro Andrade wrote:
>> Hi there,
>
> Hi Sandro,
>
>> I've been playing with Qt on Android for some weeks, trying to come up
>> with some nice approach to implement Minuet for Android/iOS. I'd like
>> to bring some topics I've been wondering for discussion here:
>>
>> * UI/UX visual language/metaphors: FWIK, we have four possible paths
>> to follow regarding that:
>>
>> 1) QML Quick Controls 1
>> 2) QML Quick Controls 2 (with Material Design, Universal Design, and
>> Default) 3) qml-material (https://github.com/papyros/qml-material)
>> 4) Kirigami (https://quickgit.kde.org/?p=kirigami.git)
>>
>> I think all of those have its strenghts and shortcomings but it'd be
>> useful if we start discussing some guidelines regarding that. Using
>> Kirigami would be obviously our first choice since we'd be promoting
>> our own visual language. QML Quick Controls 2 has a technical preview
>> in Qt 5.6 with an initial implementation of Material Design, Universal
>> Design and a "default" style for QML controls. Both Kirigami and QML
>> Quick Controls 2 are in a very early stage though, I'm unsure if they
>> are ready for use in real complex mobile applications.
>
> Kirigami is obviously the way to go. It allows us to have our own interaction
> design language and it's already being used by four KDE mobile applications
> that are in the works. It would be a shame if we didn't all use it.
> Subsurface-mobile [1] (not a KDE application) shows that even at this early
> stage, Kirigami is already well suited for complex applications (I guess
> Subsurface-mobile is pretty much as complex as it gets for a mobile app,
> they're doing some crazy stuff there) and is officially released on Android.
>
> Kirigami alone is not the solution, however, since it purposely does not offer
> basic controls. It's meant as an add-on for Qt Quick Controls, offering more
> high-level building blocks. Currently it's based on QQC 1, but it will switch
> to QQC 2 as soon as those are ready for prime-time.

I wouldn't go as far as saying Kirigami is "obviously the way to go",
but I can say that realistically, if we don't want to maintain 23 UI's
for each application is a good way to go. Kirigami needs development
still, but it can be a good base to unite again in the application
development front.

That said, I haven't been able to give QQC2 a go yet, because of it's
lack of desktop theming.

>> OTOH, qml-material looks great but it's been barely maintained. I
>> don't know if replacing a given UX visual language by another one is
>> as simple as changing the QML style adopted or if they define
>> different vocabulary which, in turn, would end up with the need of
>> changing the source code and the particular UML elements adopted. At
>> least in QML Quick Controls 2, we can easily choose between Material
>> Design, Universal Design, and the Default Design requiring only an app
>> restart. Having a standardized vocabulary with the possibility of
>> implementing UX visual languages as simple styles would be the perfect
>> scenario.
>
> Kirigami allows theming as well, that it should have you covered there.

I think it's mostly about integration. If there's no integration, who
cares about theming...?

>> * KF5-based vs Qt-based: I haven't tried to build KF5 on Android yet,
>> but I'd like to discuss to which extent they're buildable in Android
>> and actually bring some quite useful functionality. Has anyone
>> successfully built KF5 on Android? At the minimal, level 1 frameworks
>> shouldn't present any issue apart from setting up cmake environment?
>
> Kirigami is developed with the clear goal of being deployable on Android and
> iOS and will become a Tier 1 KDE Framework. I personally don't know about
> other Frameworks.

I wouldn't discuss that much. If a framework isn't working on Android,
it should be made to work.

Pushing for low tiers (such as Kirigami, which is the actual novelty
on the technical side, the tier) is a must though.

>> * Release and Deployment: has anyone tried to deploy qt apps with
>> ministro service? If we're going to have a set of qt-based
>> applications for Android, the bundled deployment option doesn't seem
>> viable. We have a store in Google App Store for KDE applications
>> (https://play.google.com/store/apps/developer?id=KDE%20Community&hl=pt_BR),
>> currently providing mobile versions of KAlgebra, KDE Connect, and
>> Behaim Globe (marble-based?). Also, we have the recent aquisition of
>> OCS by BlueSystems.
>
> Play Store is certainly the easiest way to reach most users. OCS is also a
> possible option for the future, but will require users to explicitly allow
> sideloading of APKs (if their system even allows them to do that).

Why isn't it viable? I think it's viable. If we ever have more than 30
applications and we see it's becoming a problem, we probably should
fix it, but let's not optimize before time, we have bigger problems,
such as not having good applications available.

Aleix