Mobile components and convergence

Sandro Andrade sandroandrade at kde.org
Sun Mar 27 03:10:56 UTC 2016


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? :)

Cheers,
Sandro

>
> Aleix
> _______________________________________________
> KDE-Android mailing list
> KDE-Android at kde.org
> https://mail.kde.org/mailman/listinfo/kde-android


More information about the KDE-Android mailing list