GSOC project updates

[Tomaz Canabrava]

On Mon, Jul 28, 2014 at 12:10 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> On Jul 28, 2014, at 8:03 AM, Venkatesh Shukla
> <venkatesh.shukla.eee11 at iitbhu.ac.in> wrote:
>
> On Mon, Jul 28, 2014 at 8:12 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>>
>>
>> On Jul 28, 2014, at 7:39 AM, Venkatesh Shukla
>> <venkatesh.shukla.eee11 at iitbhu.ac.in> wrote:
>>
>> > On Mon, Jul 28, 2014 at 8:03 PM, Tomaz Canabrava <tcanabrava at kde.org>
>> > wrote:
>> >> Don't reimplement things if they already work ._.
>> >
>> > Things do work but not without Qt. And subsurface-android would not
>> > have Qt dependencies. Hence, the reimplementation.
>>
>> Why? My understanding is that Qt is available for Android.
>> Thiago?
>>
>> /D
>>
>
> Anton and I have decided that it is better not to use Qt on android. Not
> using Java on android limits the things that are accessible. For instance
> the USB Host mode. My implementation using the JNI and Qt library is ugly
> and prone to bugs.
>
> Hence the plan was to dump Qt as a whole from subsurface-android and start
> fresh. Subsurface-library will be built containing all core functions needed
> on subsurface and the user interface would be Xml and Java based as is usual
> on android.
>
> This will give us two big advantages :
> 1. All core functionality of subsurface is used directly. Hence new
> developments will be valid for subsurface android as well with minor
> tweaking for UI.
> 2. All android specific functions would be available on android with
> relative ease.
>
> Now, if we remove all the qt-ui files from subsurface-build, we also lose
> some important functions which would be needed for proper functioning of
> subsurface-library. For instance, the functions of qthelper.cpp and
> translation. Hence, I was reimplementing those without using Qt libraries.
>
> Please give feedbacks on this approach.

Well, Since we ( me and thiago ) are not using subsurface only for it
to be a awesome diving app but also as a stress test of Qt on the
platforms it supports, I don't like that for a few reasons that I'll
try to explain:

*if* we do a Java - only version for android, we would need to do the
same for iOS later using Objective-C, wich will make... *4* uis. I
don't think that's good.

the Web stuff we can't run from it, since it runs everywhere that a
javascript runs, but also it's important to show our exported dives on
the web with ease.

Android is already a Supported platform on Qt ( this doesn't means
that Qt works on Android, but that Qt works on android *and* has full
support from it's developers ),

subsurface is a very complex app with has a lot of user interfaces,
recreating all those in android can be quite time consuming and error
prone ( wel, I'v spend almost one year porting stuff from gtk to qt,
port that to android libraries would also take time, then port those
to iOS ... )

I *think* we should stick to One library and try not to recreate the
well for every platform that we need to support - That was the main
reason we choose Qt.

We can use Java stuff from C++ on Android for the missing stuff on Qt
( that surely will be less and less overtime )

I would like also a hands up from thiago here, as he activelly works
on Qt, and not me yet.

> It’s not what I expected to happen and I would love to hear feedback from
> Thiago / Tomaz, but in the end this is between you and Anton to decide (in
> the context of GSOC).
> I will play with the APK later today to get an idea how this all looks.
>
> In principal I’m sad that we now will maintain three UIs - the HTML/JS one,
> the Java one, the Qt one. But I guess it is what it is.
>
> /D
>