GSOC project updates
glance at acc.umu.se
Mon Jul 28 09:03:22 PDT 2014
On 28 July, 2014 - Venkatesh Shukla 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.
Just a note here from how we thought.
The scope of this GSOC project is to produce a usable downloader app
for android and one pre-req for that is a usable touch friendly ui.
The current Android port of subsurface is unusable as a ui, but it
works as a technical product. It needs a better ui for touch.
We could do that with QT/Qml, and that was one option.
The other option was to re-use the "backend" parts of subsurface and
build a Android-native ui _just_ for the download parts.
We could also mix and match the two, with some parts in Qt, and some in
I and Venkatesh discussed this over IRC and as Venkatesh felt more
conftable with doing a touch ui for Android in "native" Java we decided
to go that path.
This is nothing that can't be changed in the future, but for now,
Venkatesh felt most comfortable with the subsurface "backend" approach
and a Java ui calling into that code.
Anton Lundin +46702-161604
More information about the subsurface