Subsurface 4.7 / 5.0

[Lubomir I. Ivanov]

On 21 January 2017 at 20:44, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> hello,
>
> On 21 January 2017 at 13:01, Anton Lundin <glance at acc.umu.se> wrote:
>> On 20 January, 2017 - Dirk Hohndel wrote:
>>
>>> On Fri, Jan 20, 2017 at 05:06:40PM +0100, Tomaz Canabrava wrote:
>>> >
>>> > Other option is to try to make next Subsurface the Subsurface 4.7:
>>> >
>>> > Continue duplicating code for the Mobile version (that has a small userbase
>>> > but will probabbly gain an increase of usage over the years) and cleaning /
>>> > improving the Desktop version, changing things on the core as little as we
>>> > need.
>>>
>>> Or, how about option 3:
>>>
>>> Forget about Subsurface-mobile. Wait a year for Kirigmi 7 that uses QML3
>>> and and Qt.Slow.Conniptions.4 and then revisit if we want to waste another
>>> year of our time on something that more or less no one is interested in
>>> using.
>>>
>>
>> I'm still tempted to revive the branch where I bult subsurface-core as a
>> library with jni wrappers and build a UI in Android native java.
>>
>> There are enough competence and tutorials out there so almost anyone can
>> hack on a Android java app, and the "core" parts of subsurface, we
>> already know.
>>
>
> i haven't followed the mobile app much (+all the troubles surrounding
> it) expect that i filed a report of one nasty QML GridLayout bug at
> the Qt bugtracker at one point; it was a pretty bad showstopper. i've
> also found some more bugs in QML elements later. maybe QML and the
> frameworks for it are still not ready...but hmm, it has been at least
> 3 years since QML started advertising itself for mobile, so not sure
> what's going on that front. maybe Kirigami was bad choice here...
>
> other than that, i can help as much as time permits with the native
> Android UI as i've been doing exactly that the past couple of years.
> that native Android also has it's perks here and there, but it's quite
> good and easy to get into...of course, so as many probably know
> already - not a single UI toolkit is optimal.
>
> and i guess a native Android UI, would mean that a native iOS UI has
> to be written.
>

above typos aside, i would like to quickly point out something about
multiplatform mobile development and the horror story it is.

after many trials with my employer, trying pretty much everything from
A to Z which is available out there, free or payware to be able to
target both iOS and Android at the same time with a single UI toolkit,
in a sane matter, good programming language, without bugs etc, i've
come to the conclusion that - multiplaform mobile development is
(still) a myth.

Xamarin, Adobe AIR, Qt + QML, Codename1, JS toolkits etc...all of them
are either buggy, awkward to use or have major limitations.
so for me ATM, the only sane way to approach mobile development is to
develop native UI.

lubomir
--