[Development] QML bindings for native Android controls

[Nurmi J-P]

Hello,

I'd like to request a playground repository for the former hackathon project of mine: QML bindings for native Android controls -

Before proceeding to a formal request, the baby needs a name. I was hoping you could help me choose one.

Factors that affect the naming:
- This is not cross-platform, but highly Android specific. The convenience of QML and and full access to the underlying platform APIs combined.
- This is not integrated with Qt Quick. Only QML engine & native controls (via JNI) are used. Gives great performance with 100% perfect native behavior.

Credits for the groundwork go to Attila Csipa
- http://achipa.blogspot.no/2014/11/qml-wrappers-for-native-android.html
- http://achipa.blogspot.no/2014/11/native-ui-in-qt-on-android-without.html

--
J-P Nurmi

[Robert Knight]

Post by Nurmi J-P
I'd like to request a playground repository for the former hackathon project of mine: QML bindings for native Android controls - http://youtu.be/Mo8J-g5XPGQ

This looks great and IMO the only way to be sure of being able to
create a top-tier UX for Android or iOS for an app that is intended to
have a native look and feel.

Are repositories like this best served living with the other Qt
playground repos though? I wonder whether it might be able to gain
traction faster if it was on GitHub instead?

Post by Nurmi J-P

Post by Nurmi J-P
Hello,
I'd like to request a playground repository for the former hackathon project of mine: QML bindings for native Android controls - http://youtu.be/Mo8J-g5XPGQ
Before proceeding to a formal request, the baby needs a name. I was hoping you could help me choose one.
- This is not cross-platform, but highly Android specific. The convenience of QML and and full access to the underlying platform APIs combined.
- This is not integrated with Qt Quick. Only QML engine & native controls (via JNI) are used. Gives great performance with 100% perfect native behavior.
Credits for the groundwork go to Attila Csipa
- http://achipa.blogspot.no/2014/11/qml-wrappers-for-native-android.html
- http://achipa.blogspot.no/2014/11/native-ui-in-qt-on-android-without.html
--
J-P Nurmi

It looks cool!
QtBuzzDroid
CuteBuzzDroid
jm2c
Regards,
Robert
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development

[Nurmi J-P]

Post by Robert Knight

Post by Nurmi J-P
I'd like to request a playground repository for the former hackathon project of mine: QML bindings for native Android controls - http://youtu.be/Mo8J-g5XPGQ

This looks great and IMO the only way to be sure of being able to
create a top-tier UX for Android or iOS for an app that is intended to
have a native look and feel.

Indeed. UIs have come a long way since the days of Windows 95 and others where it was sufficient to draw buttons and checkboxes a bit differently. These days, UIs are full of little transitions and effects. When those things are missing or slightly off, the UI feels broken.

Post by Robert Knight
Are repositories like this best served living with the other Qt
playground repos though? I wonder whether it might be able to gain
traction faster if it was on GitHub instead?

I’m afraid it has to be covered by the Qt CLA ie. hosted by the Qt project.

--
J-P Nurmi

[Attila Csipa]

Post by Nurmi J-P
Indeed. UIs have come a long way since the days of Windows 95 and
others where it was sufficient to draw buttons and checkboxes a bit
differently. These days, UIs are full of little transitions and
effects. When those things are missing or slightly off, the UI feels
broken.

Amen to that.

When you not only try to reimplement everything a company on the scale
of Google/Apple/Msft/etc did, but also try to do it in source compatible
way, you're in for a lot of trouble. The choice is basically either the
UI equivalent of death-by-a-thousand-papercuts you outlined or a really
rough lowest-common-denominator approach (which is really low nowadays
given all the various interaction patterns the different platforms
have). Add to this the various multimedia and mobile API implications,
it quickly becomes a compatibility-matrix lottery.

If one wants a JavaScript-driven declarative UI that works on a "most of
the time" basis, web/hybrid apps fill the need pretty well, even if
60fps interfaces are a bigger challenge (let's not mix bad JS code with
tech limitations here). QtQuick is awesome if you want to make a custom
UI (one of the reason it's doing so well in embedded space), but on real
cross-platform (especially mobile) apps it's a bit out of the water,
despite the progress of QtQuick.Controls, and IMO it will never quite
"get there" given the constant flow of new OS versions, widgets, design
patterns, etc. And, as I discovered, #ifdefs are a really poor way of
handling cross-platform development (they are far better at
feature-management than platform-management), so the old-school C++
approach is really not helping there either.

What is sorely needed is a fast, prototyping-friendly and
platform-agnostic way of doing UIs while relying on their native
implementation of widgets, usage patterns, libraries etc. Yes, even if
it means giving up the single-codebase dream. QML and it's C++
integration does this quite well (broken-by-design quirks
notwithstanding), and that's why wrapper component-sets like this one
are a giant step in the right direction.

Best regards,
Attila

[Nurmi J-P]

Post by Nurmi J-P

Post by Nurmi J-P
Hello,
I'd like to request a playground repository for the former hackathon project of mine: QML bindings for native Android controls - http://youtu.be/Mo8J-g5XPGQ
Before proceeding to a formal request, the baby needs a name. I was hoping you could help me choose one.
- This is not cross-platform, but highly Android specific. The convenience of QML and and full access to the underlying platform APIs combined.
- This is not integrated with Qt Quick. Only QML engine & native controls (via JNI) are used. Gives great performance with 100% perfect native behavior.
Credits for the groundwork go to Attila Csipa
- http://achipa.blogspot.no/2014/11/qml-wrappers-for-native-android.html
- http://achipa.blogspot.no/2014/11/native-ui-in-qt-on-android-without.html
--
J-P Nurmi

It looks cool!
QtBuzzDroid
CuteBuzzDroid
jm2c
Regards,
Robert

Thanks for the ideas, keep it coming! :) We should probably follow the guidelines: https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt

--
J-P Nurmi

[Harri Pasanen]

Name candidates: QML-Droid or QDroid

Btw, can QML do layouting of Android widgets, or is that left for the
android layout engine?

Harri

Post by Nurmi J-P

Post by Nurmi J-P

Post by Nurmi J-P
Hello,
I'd like to request a playground repository for the former hackathon project of mine: QML bindings for native Android controls - http://youtu.be/Mo8J-g5XPGQ
Before proceeding to a formal request, the baby needs a name. I was hoping you could help me choose one.
- This is not cross-platform, but highly Android specific. The convenience of QML and and full access to the underlying platform APIs combined.
- This is not integrated with Qt Quick. Only QML engine & native controls (via JNI) are used. Gives great performance with 100% perfect native behavior.
Credits for the groundwork go to Attila Csipa
- http://achipa.blogspot.no/2014/11/qml-wrappers-for-native-android.html
- http://achipa.blogspot.no/2014/11/native-ui-in-qt-on-android-without.html
--
J-P Nurmi

It looks cool!
QtBuzzDroid
CuteBuzzDroid
jm2c
Regards,
Robert

Thanks for the ideas, keep it coming! :) We should probably follow the guidelines: https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt
--
J-P Nurmi
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development

[Nurmi J-P]

Post by Harri Pasanen
Name candidates: QML-Droid or QDroid

Various derivatives from Droid seem to be popular. Does it not fall to the “any play on names” or “slang in names” categories?

http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt

Post by Harri Pasanen
Btw, can QML do layouting of Android widgets, or is that left for the
android layout engine?

So far I have just exposed the Android layouts, but implementing anchors is on the wishlist. That would make Qt Quick developers feel at home. Android’s RelativeLayout does not quite feel the same.

[Harri Pasanen]

Post by Nurmi J-P

Post by Harri Pasanen
Name candidates: QML-Droid or QDroid

Various derivatives from Droid seem to be popular. Does it not fall to the “any play on names” or “slang in names” categories?
http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt

How about then qml-native ?

I would give a hint that it is somewhat akin to react-native, and allows
for migration to other targets while keeping the name.

So at least in theory it could target ios, windows phone as well...

Harri

[Attila Csipa]

IANAL but using "for Android" should be fine w both Google and Qt (just
stick the TM notice in your docs). I'm leaning towards Controls for
Android (or, maybe QML for Android). It can still have a name of it's
own (pick your favorite dog name or noun), but a descriptive name would
IMO go a long way to understand what this is about, especially as it can
be confusing as to how it relates to other Qt modules and technologies.

Best regards,
Attila Csipa

Post by Nurmi J-P

Post by Harri Pasanen
Name candidates: QML-Droid or QDroid

Various derivatives from Droid seem to be popular. Does it not fall to the “any play on names” or “slang in names” categories?
http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt

Post by Harri Pasanen
Btw, can QML do layouting of Android widgets, or is that left for the
android layout engine?

So far I have just exposed the Android layouts, but implementing anchors is on the wishlist. That would make Qt Quick developers feel at home. Android’s RelativeLayout does not quite feel the same.
--
J-P Nurmi
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development

[Robert Knight]

Post by Attila Csipa
What is sorely needed is a fast, prototyping-friendly and
platform-agnostic way of doing UIs while relying on their native
implementation of widgets, usage patterns, libraries etc.

Xamarin and React Native are aiming to get as close to that as
feasible without compromising
on design - which means that they explicit DON'T promise "write once,
run anywhere" because
the UX is not the same across platforms.

What they promise instead is 'learn once, run anywhere' - that is, use
the same language, tools and non-UI
logic across apps.

React Native is very new (but very promising) but I'd be interested to
hear if anyone has experience of what development of large
apps with Xamarin is like vs. Qt for mobile?

Post by Attila Csipa
IANAL but using "for Android" should be fine w both Google and Qt (just
stick the TM notice in your docs). I'm leaning towards Controls for
Android (or, maybe QML for Android). It can still have a name of it's
own (pick your favorite dog name or noun), but a descriptive name would
IMO go a long way to understand what this is about, especially as it can
be confusing as to how it relates to other Qt modules and technologies.
Best regards,
Attila Csipa

Post by Nurmi J-P

Post by Harri Pasanen
Name candidates: QML-Droid or QDroid

Various derivatives from Droid seem to be popular. Does it not fall to the “any play on names” or “slang in names” categories?
http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt

Post by Harri Pasanen
Btw, can QML do layouting of Android widgets, or is that left for the
android layout engine?

So far I have just exposed the Android layouts, but implementing anchors is on the wishlist. That would make Qt Quick developers feel at home. Android’s RelativeLayout does not quite feel the same.
--
J-P Nurmi
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development

_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development

[Attila Csipa]

Hi,

IMO Xamarin has (or at least had) a more modern approach, and since
mobile was their bread-and-butter, they put a lot of effort there, and
it really shows. I have some experience with it, so (again IMO) various
gotchas notwithstanding, on *mobile*, it is considerably more mature
than the Qt offering of today, even if I prefer QML over XAML any day.
The way I see it, Qt's strong points are really in the desktop/embedded
area and the (L)GPL licensing. I'm a bit afraid Xamarin will give in to
the dark side (Xamarin.Forms and the related tooling does try to sell
the single shared codebase dream, even if it's backed by native
controls). No real experiences with React Native yet...

Best regards,
Attila

Post by Robert Knight

Post by Attila Csipa
What is sorely needed is a fast, prototyping-friendly and
platform-agnostic way of doing UIs while relying on their native
implementation of widgets, usage patterns, libraries etc.

Xamarin and React Native are aiming to get as close to that as
feasible without compromising
on design - which means that they explicit DON'T promise "write once,
run anywhere" because
the UX is not the same across platforms.
What they promise instead is 'learn once, run anywhere' - that is, use
the same language, tools and non-UI
logic across apps.
React Native is very new (but very promising) but I'd be interested to
hear if anyone has experience of what development of large
apps with Xamarin is like vs. Qt for mobile?

Post by Attila Csipa
IANAL but using "for Android" should be fine w both Google and Qt (just
stick the TM notice in your docs). I'm leaning towards Controls for
Android (or, maybe QML for Android). It can still have a name of it's
own (pick your favorite dog name or noun), but a descriptive name would
IMO go a long way to understand what this is about, especially as it can
be confusing as to how it relates to other Qt modules and technologies.
Best regards,
Attila Csipa

Post by Nurmi J-P

Post by Harri Pasanen
Name candidates: QML-Droid or QDroid

Various derivatives from Droid seem to be popular. Does it not fall to the “any play on names” or “slang in names” categories?
http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt

Post by Harri Pasanen
Btw, can QML do layouting of Android widgets, or is that left for the
android layout engine?

So far I have just exposed the Android layouts, but implementing anchors is on the wishlist. That would make Qt Quick developers feel at home. Android’s RelativeLayout does not quite feel the same.
--
J-P Nurmi
_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development

_______________________________________________
Development mailing list
http://lists.qt-project.org/mailman/listinfo/development

[Jeremy Lainé]

Post by Nurmi J-P
Thanks for the ideas, keep it coming! :) We should probably follow the
guidelines: https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt

How about just "android-controls", which would become
"qt-android-controls" if the project graduates from playground?

Cheers,
Jeremy

[Nurmi J-P]

Post by Jeremy Lainé

Post by Nurmi J-P
Thanks for the ideas, keep it coming! :) We should probably follow the
guidelines: https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt

How about just "android-controls", which would become
"qt-android-controls" if the project graduates from playground?

I like this suggestion. In the end we will have much more (*) than just UI controls, though. Does that matter from the naming perspective?

*) For example, good background service integration is important for my own use cases. Pretty much the same way WorkerScript works, I hope to be able to send arbitrary jsobjects between background services and UI instances.

--
J-P Nurmi

[Jeremy Lainé]

Post by Nurmi J-P

Post by Jeremy Lainé
How about just "android-controls", which would become
"qt-android-controls" if the project graduates from playground?

I like this suggestion. In the end we will have much more (*) than just UI controls, though. Does that matter from the naming perspective?
*) For example, good background service integration is important for my own use cases. Pretty much the same way WorkerScript works, I hope to be able to send arbitrary jsobjects between background services and UI instances.

Another option is "quick-android", which would become "qt-quick-android".

Cheers,
Jeremy

[Nicolás Ulrich]

Post by Jeremy Lainé

Post by Nurmi J-P

Post by Jeremy Lainé
How about just "android-controls", which would become
"qt-android-controls" if the project graduates from playground?

I like this suggestion. In the end we will have much more (*) than just

UI controls, though. Does that matter from the naming perspective?

Post by Jeremy Lainé

Post by Nurmi J-P
*) For example, good background service integration is important for my

own use cases. Pretty much the same way WorkerScript works, I hope to be
able to send arbitrary jsobjects between background services and UI
instances.

Post by Jeremy Lainé
Another option is "quick-android", which would become "qt-quick-android".
Cheers,
Jeremy

+1

I would love to try this so any name is good for me. I was just starting to
develop something for android (in java) just because qtquickcontrols
doesn't feel right. This however is really encouraging.

Do/will the standard Qt models work with the native views?

[Nurmi J-P]

I would love to try this so any name is good for me. I was just starting to develop something for android (in java) just because qtquickcontrols doesn't feel right. This however is really encouraging.

This is looking very promising, but don’t get too excited yet. :) This is not a finished product, just a hackathon project that I haven’t actually touched since December because I’ve been busy with http://blog.qt.io/blog/2015/03/31/qt-quick-controls-for-embedded/.

Do/will the standard Qt models work with the native views?

The example seen in the video is using a JS array as a model for the sake of simplicity, but the same set of models that Qt Quick supports (number, JS arrays, QObjectList, QAbstractItemModel, QQmlXxxModel...) is on the wish list.

[Nurmi J-P]

Post by Nurmi J-P

Post by Jeremy Lainé
How about just "android-controls", which would become
"qt-android-controls" if the project graduates from playground?

I like this suggestion. In the end we will have much more (*) than just UI controls, though. Does that matter from the naming perspective?
*) For example, good background service integration is important for my own use cases. Pretty much the same way WorkerScript works, I hope to be able to send arbitrary jsobjects between background services and UI instances.

Another option is "quick-android", which would become "qt-quick-android”.

I’d like to avoid the “quick" word, because this is incompatible with Qt Quick.

--
J-P Nurmi