On 28 July 2014 18:40, Tomaz Canabrava <[email protected]> wrote: > > 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 ) >
^ this. i don't have much of a vote here, but the idea by Anton and Venkatesh to create the UI in Java and use Subsurface as a library on Android gets a -1. to me it seems that the task is underestimated here..by .a lot. the "subsurface as a library" part alone is a ton of work if i overview this correctly. Qt 5.2+ with some of the things like QAndroidJniObject, QAndroidJniEnvironment is the way to go, ugly or not. no comments on GSOC specifics. lubomir -- _______________________________________________ subsurface mailing list [email protected] http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
