On Mon, Jul 28, 2014 at 12:10 PM, Dirk Hohndel <[email protected]> wrote: > > On Jul 28, 2014, at 8:03 AM, Venkatesh Shukla > <[email protected]> wrote: > > On Mon, Jul 28, 2014 at 8:12 PM, Dirk Hohndel <[email protected]> wrote: >> >> >> On Jul 28, 2014, at 7:39 AM, Venkatesh Shukla >> <[email protected]> wrote: >> >> > On Mon, Jul 28, 2014 at 8:03 PM, Tomaz Canabrava <[email protected]> >> > 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 > _______________________________________________ subsurface mailing list [email protected] http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
