Mobile components and convergence

[Aleix Pol]

On Sun, Mar 27, 2016 at 5:10 AM, Sandro Andrade <sandroandrade at kde.org> wrote:
> On Wed, Mar 23, 2016 at 10:36 PM, Aleix Pol <aleixpol at kde.org> wrote:
>> 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.
>
> I've tried Kirigami components and QQC 2 and have to say they are still
> far behind the nice look&feel qml-material currently provides :( I think the
> best we can do now is discuss what is required to take Kirigami to production
> level. Do we have a full visual language specification from VDG? Do we keep
> track of how much of that was already implemented in Kirigami? Are we pushing
> that forward enough? I see no projects for that in our GSoC 2016 ideas page :)
> Should we move that discussion to plasma-devel?
>
>>
>> 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.
>
> Yes, I agree.
>
>>
>> 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.
>
> Sure but bundling Qt libs in every app we publish makes the simplest
> application already a burden to install -- I have a quite simple Qt for
> Android application ocupping nearly 60Mb of storage. Having that multiple
> times in a single device might make things infeasible. Am I missing
> something? :)

60MiB is too much, I'm sure you can cut stuff.

Aleix