[Android-development] On False Promises ...

Mon Jan 6 17:06:19 CET 2014

Hi Eskil,

Thanks very much for you time reading this long email :) Let me make a few
things more clear (inline)

On Mon, Jan 6, 2014 at 4:35 PM, Eskil Abrahamsen Blomfeldt <
eskil.abrahamsen-blomfeldt at digia.com> wrote:

>  On 01/06/2014 01:29 PM, Rubi Mazaki wrote:
>
>  Finally! I managed to deploy the QML app to the Android device. It even
> run after showing me weird errors about QML debug info that is missing
> from my application. Whatever I said. This will not stop me. QML can be
> debugged on the computer, and C++ is better anyway (considering that Native
> UI components are out of the scope anyway?)
>
>
> Hi!
>
> We should be able to get the same level of support for native UI
> components in Qt Quick Components as in Qt Widgets, but it requires some
> work. It is definitely not regarded as "out of scope", but the focus of Qt
> Quick Components so far has been the desktop platforms.
>

Are QML objects designed to appear as iOS/Android controls look and feel?
AFAIK this is not the general design. QML controls seem to be designed more
for custom UI, custom buttons, .. .etc. Not that it's bad. It's just not
NativeUI controls (AFAIK). Other cross-platform frameworks did that by
wiring the native controls, in their native language to C++/Js (to name a
few: Mosync/Marmalade/Appcelerator) - These frameworks are very strong with
that aspect. Qt has quite a hole in that aspect.

>
>  These are small things. But they put Qt in a very bad light.
>
> My Proposal:
> 1. Downloads can be put to torrents. Even with open source resources – Let
> some people be the “torrent keepers” (I volunteer my home connection at day
> time..) use uTorrent and leave the downloads open.
>
>
> This seems like a general suggestion for the Qt Project. Try asking on the
> main mailing list. There might be interest in joining you on creating
> torrent-based distribution. Currently there is a network of mirrors serving
> the downloads in the Qt Project, and I haven't experienced any slow
> downloads there myself. Could this be bad timing for your download, or have
> you experienced this several times? Note that we did distribute Qt over
> torrent back when Qt 4 was released in 2005, but it never really caught on
> as far as I remember.
>
> I already posted a manifest about that :) here: http://qt-project.org/forums/viewthread/36777/

>
>   2. Add Android installations (sdk/ndk) into the Android installer. Make
> it setup the paths right to the environment.
>
>
> In order to install Google's NDK and SDK, the user has to accept the
> licenses on Google's download page, so it can unfortunately not be
> distributed with the Qt SDK (non-redistributability is actually part of the
> license as far as I've understood). So this is not a trivial issue,
> legally. We have discussed the possibility of making these available
> through Qt's online installer, somehow displaying the correct license for
> the downloads there, but so far we haven't committed to any solution but
> chosen rather to document the process, since there are a number of
> unknowns. If the documentation for getting started with Qt for Android is
> unclear, we would very much like to hear about your specific complaints,
> since this is something we continually improve. Personally, I think that
> with proper documentation, users will be able to download these two
> external packages and set the paths themselves, so our first priority
> should be to make the documentation complete.
>
> I understand that this is not a simple task (legally). And it was probably
discussed internally, but still, it would be appreciated, and it is indeed
needed that the user/developer gets the links for the download - somehow...
and best, as part of the installation. As an example - Appcelerator does
that in their installer - it opens the google sdk download. Why can they?

> I'm not entirely sure what path hell you were referring to earlier in your
> mail. As long as you use the Qt binary package and set the four paths asked
> of you in the Android settings, then you should be set to go. If you have
> not done this, then a link to the settings should appear when configuring
> the kit for your project. We've attempted to make the steps clear in the UI
> without pushing modal dialogs in your face, striving for a less noisy UI
> design.
>

I guess it's complex to support the permissions / AndroidManifest.xml on
the first Qt version with Android. I guess this is not in priority, it's
ok, but at least it should be sufficiently simple for a developer to know
how to override the AndroidManifest.xml. This is very basic Android
development.

>
>   3. Remove all samples from the directory and enter them back, one by
> one, once they are adapted for mobile development! It is better if there
> are no samples at all at first !!!
>
>
> I'm picturing a general installation of Qt as having both desktop and
> mobile versions side by side (this is also the case in the binary
> installation). In this case, you would likely want to see the examples that
> work better on desktop even if you have an Android-based kit among your
> other Qt versions. What we could do here would be to distribute a set of
> appropriate examples with the Android kit so that you can see them by
> selecting the correct Qt version in the example page in Creator. However,
> this will probably still confuse novice users, since they'll never know to
> change the default in there. I agree that the current setup is not ideal,
> but right now I don't know exactly how it should ideally look.
>
> As for the non-working examples: Most of the examples I've tried have
> worked for me. Some of the Qt Widgets examples will look bad because they
> have not been written to work below their minimum sizes (basically they're
> specifically written to run well on a desktop system), but they will still
> work as designed. As you mentioned, Qt WebKit has not been ported to
> Android, so those examples will not work, but you should have got an error
> message about this when trying to compile these examples. Same for examples
> that depend on desktop GL, DBUS, etc.
>
>
The android installer is separated from the other desktop installers. In
fact the samples are only provided in the x86 android installer and not
under arm-v5/7. I guess it runs under x86 emulator well - as the emulator
does not require app permissions.

>
>   4. armv5/7 ?? what are these? we don’t know… You need to let the
> developer know what to choose.. when to use arm5 and when arm7. Best if
> this is available in the GUI of QtCreator.
>
>
> Having some extra descriptions in the UI would be a good idea, yes. The
> different ABIs supported by Android are mentioned in several locations in
> the Android documentation and when uploading to the Play store. I think
> that the architecture fragmentation is something you will have to deal with
> in order to do native development on Android, but this might not be
> completely familiar to someone coming from a background of developing on
> other platforms, so we could help them out by adding a tooltip for
> instance. Creator should currently be helpful at least in the respect that
> if you select an ABI which is incompatible with the device you have
> connected, you will be informed of this when trying to run it. Switching to
> a new kit should then be quite quick and easy.
>
> Yep - a tool tip would be great! Especially if it says this is for that
phone and this is for newer phones.. or something more precise.

>
>   5. If QML debugging is not supported on a real phone, don’t even let me
> start the deployment. It is much more constructive for the developer to
> know what he/she can’t do at development time, and not after the deployment…
>
>
> QML debugging should be supported, so this sounds like a bug to me.
>

I will look into that.

>
>  Hope my “recommendations” will fall hard on good ears :)
>
>
> Thank you very much for your suggestions and feedback. I hope you can also
> take the time to report them in the bug report system:
>
>     http://bugreports.qt-project.org
>
> Having them in the bug report system will ensure that they're prioritized
> properly and will prevent them from being forgotten :)
>
>
> -- Eskil
>
> _______________________________________________
> Android-development mailing list
> Android-development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/android-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/android-development/attachments/20140106/6a5db714/attachment.html>