Alpha4 release status

Willy Gardiol willy at gardiol.org
Mon Jun 11 06:50:01 UTC 2012 

I just want to add my 2cents.

I agree with one big thing: get Necessitas working _well_ at least for 
something, soon... as soon as possible!

I have a quite actvie userbase for my app on Symbian. They are very 
supportive but are all switching slowly to Android... unless i can start 
supporting Android within the next months (september, october at most, 
something usable for real by december to anticipate the Christmas rush 
to android), i am going to lose them for good to the various apps like 
mine already android native. I bet this is true for most of Qt/Symbian 
apps.

I think if something does not start working good soon, most of the 
interest in Qt for Android will decrease. Myself i am starting thinking 
about rewriting my codebase to achieve a total separation ui-core and, 
in fall, to work on an native andorid UI if i have to.

Technical considerations apart, my fear is that either necessitas is 
not ready to give something usable at least on some arch, or it will 
never catch on. Unless a substantial numebr of apps start using 
Necessitas, it will just be another framework out there, one with a huge 
download requirement which is less appealing than others.

So my appeal is: forget perfection, get out something usable quickly 
please! Honestly, alpha2 was _more_ usable than alpha3, and ICS made 
just thing worse. Alpha4 is late, i have ICS users (a few, but...) 
pissed off and switching away.

I know i have never contributed actively, and this i feel like a shame 
on me, but all my free time is already taken up by supporting Symbian, 
and i am too just one developer on the project like the BogDan so i both 
understand him and fully support him. I know it's hard when you don't 
have time but people keep hitting on you with requests and bugs!

Maybe we could help BogDan, if not using time, at least helping him get 
a new, powerfull laptiop to speed up compilation time?

Il 10.06.2012 22:06 Harri Pasanen ha scritto:
> Reading David Turner's mail from [1], it seems that Android atomics
> are not SMP safe either, so in that sense using those is not any
> better than Qt atomics?
>
> In your solutions list you refer "fast atomics", but what are those?
> If I understood you correctly, there are 3 options, Qt, android and
> gcc.   First two are fast but not SMP safe, last is slow but SMP 
> safe.
>
> Are you saying that Qt armv7 is SMP safe and fast?
>
> If so, I'd vote for dropping arm5 support.  It would also make the
> development/testing cycle faster with one less architecture to
> support.   Usually arm5 devices are so low end with
> memory/screen/speed wise that they don't work well in any case.
>
> I'd rather have a Qt that is ready and working well for a subset of
> devices than none at all.
>
> I don't care about backward compatibility for my Qt Android apps
> (yet).   I can always recompile those, and if I don't, the deserve to
> die.   While it is in Alpha this is expected.  Once in beta, 
> backwards
> compatibility is required.
>
> The way I see it, Qt/Necessitas can get lots of new developers
> interested for new projects if basics and new stuff works well. So 
> I'd
> worry about new devices, Qt 5/QML, and try to trim down work required
> on maintenance type activities.   So from my perspective QtWidgets,
> arm5, backwards compatibility all can be dropped now.
>
> Anyways, keep up the good work!
>
> Just my 2 cents,
>
> Harri
>
>
>
>
> On 06/10/2012 09:15 PM, BogDan Vatra wrote:
>> Hi,
>>
>> Many thanks for kind words !
>>
>> Sadly, the magic happened :). The good news is that it was my fault,
>> the bad news it that my worst nightmare happened ... :(
>> After I write my first mail I begin to cherry-pick all my changes 
>> from
>> alpha4 and put them on top of alpha3 branch, then I spot a patch 
>> which
>> caught my attention, and I really hoped it's not the cause of this
>> problem, but it was ...
>> Some time ago somebody complained on this mailing list about the 
>> fact
>> that he could not be able to compile necessitas anymore using 
>> ndk-r7,
>> soon I discovered that the atomics functions where not exported
>> anymore in ndk-r7, then my nightmare began, first I post the problem
>> on android-ndk mailing list[1], then Google suggest me that I should
>> switch to gcc's built in atomics which I did[2]. I knew that the gcc
>> built in atomics are not the fastest in the world, but I never 
>> thought
>> that they are that bad. Android atomics support on necessitas is a
>> long story, which began more than a year ago, I'll try to make it
>> shorter for you :)
>> For the very first android atomics implementation, I used Qt's arm
>> atomics, but I had to switch to gcc built-in atomics (yes, the 
>> second
>> implementation was based on gcc atomics) because Qt's arm5 atomics
>> where useless for Android, I'll try to explain why: The problem is
>> that Qt's arm5 atomics are not SMP safe, so, is probable that your 
>> app
>> will crash on a dual-core device. arm5 is very important because it 
>> is
>> supported by all arm android devices, so it must be SMP safe. I
>> address this problem last year at QCS[3], and somebody offer to 
>> help,
>> but sadly nothing happened. So, I had to find a solution myself, 
>> GCC's
>> implementation is using a sort of memory barrier (a mutext or
>> something) to make it SMP safe, that why is so slow, then I discover
>> that google is providing atomics in libc, which they should be SMP
>> safe, so I switched to android atomics, then google change their 
>> mind
>> and now they are dropping the support, so I had to switch back to 
>> gcc.
>>
>> To "fix" this problem I see the following "solutions":
>> 1. Ignore Google warning and keep using android atomics.
>> 2. Stay with gcc atomics, but is too slow.
>> 3. Build Qt libs with fast atomics, but find a way to have safe
>> atomics for arm5.
>> 4. Build Qt libs with fast atomics, but use GCC atomics for apps.
>> 5. Build Qt libs with fast atomics, but don't make qt atomics inline
>> anymore, this way your apps will use what qt provides for that
>> platform. They will be a little by slower but they should be safe.
>> This is my favorite solution, but I afraid that it will break the 
>> ABI
>> ...
>>
>> It is safe to build Qt libs with fast atomics for arm5 because arm5
>> libs will be downloaded Ministro *only* on arm5 devices and AFAIK
>> there is no SMP arm5 device. The problem is that your apps are not
>> downloaded by Ministro :) and if they are built only using armv5 
>> they
>> will be loaded by a SMP device and they will have problems, so arm5
>> atomics must be SMP safe.
>>
>> Anyway we have to address the problem once and for all !
>>
>> If any of you has any other Ideas please don't hesitate to share 
>> them with us.
>> Also any comments/feedback will be very appreciated.
>>
>> Cheers,
>> BogDan.
>>
>>
>> [1] 
>> https://groups.google.com/group/android-ndk/browse_thread/thread/a792d8392b01f389/ecbad8bb4981ed8d
>> [2] 
>> http://commits.kde.org/android-qt/aa14a65fd29f20adb7aa22b354c975d76266bed1
>> [3] http://community.kde.org/Necessitas/Meetings/QtCS2011
>>
>>
>> 2012/6/10 Bruno Zerbo<bruno.zerbo at gmail.com>:
>>> Thanks BogDan for your work.
>>> cheers,
>>> Bruno
>>>
>>>
>>> 2012/6/10 BogDan Vatra<taipanromania at gmail.com>
>>>> Hello folks,
>>>>
>>>>   Unfortunately I have more bad news regarding alpha4 release, I
>>>> manage to fix the OpenGL problem, but I discover another one. The
>>>> startup of all applications has slowdown a lot (2-4 times), the
>>>> problem is the difference between alpha3 and alpha4 is huge (1000+
>>>> patches). Alpha3 is based on Qt 4.8.0-rc and alpha4 is based on Qt
>>>> 4.8.2, to be sure the problem is not caused by me, I have to
>>>> cherry-pick all my changes and put them on top of alpha3, them, if 
>>>> is
>>>> not my fault the pain begins, I'll have to merge Qt 4.8.0, check, 
>>>> then
>>>> Qt 4.8.1, then Qt 4.8.2. This is going to be a very slow and 
>>>> painful
>>>> process which will take days (even weeks) so, I don't believe 
>>>> alpha4
>>>> will be out before QCS, unless a miracle happens and I'll found 
>>>> the
>>>> issue in the next days.
>>>>
>>>> Sorry for the bad news ...
>>>>
>>>> Cheers,
>>>> BogDan.
>>>>
>>>>
>>>> 2012/6/4 BogDan<taipanromania at gmail.com>:
>>>>> This 
>>>>> http://files.kde.org/necessitas/installer/MinistroActivity.apk is
>>>>> the link to Ministro.
>>>>>
>>>>> BogDan.
>>>>>
>>>>>
>>>>> On Jun 4, 2:02 pm, BogDan Vatra<taipanroma... at gmail.com>  wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>>   As you may know the alpha4 release is approaching, the plan is 
>>>>>> to
>>>>>> have it ready before Qt Contributors Summit. It is almost 
>>>>>> completed, I
>>>>>> need a few days to polish the style plugin and Minitro and 
>>>>>> another few
>>>>>> to add support for context menus.
>>>>>>
>>>>>>    A few days ago I pushed to Minnistro's "unstable" repository 
>>>>>> the
>>>>>> current alpha4 branch in order to check if the existing released 
>>>>>> apps
>>>>>> are still working. Even we've made some heavy changes and even 
>>>>>> if I
>>>>>> warn you that it may break the compatibility with older 
>>>>>> versions, I
>>>>>> wanted alpha4 to be backward compatible with alpha3, it is also 
>>>>>> a test
>>>>>> for Necessitas developers to see if we can keep our promise: to 
>>>>>> ship
>>>>>> releases which are backward compatible!
>>>>>>
>>>>>> If you want to try it yourself please follow the next two steps:
>>>>>>   - uninstall official Ministro and use this
>>>>>> onehttp://files.kde.org/necessitas/MinistroActivity.apk.
>>>>>>   - install and run Ministro configuration tool (from market) 
>>>>>> and
>>>>>> choose unstable repository.
>>>>>>
>>>>>> Don't forget that Ministro is not stable and it may crash/hang, 
>>>>>> if you
>>>>>> encounter any problems please reply on this thread.
>>>>>>
>>>>>> Shorty after the repository was ready, I tried a few apps from 
>>>>>> market
>>>>>> and two major problems pop up:
>>>>>> - The first problem was related to some missing symbols and was 
>>>>>> caused
>>>>>> by compilation/linking flags.
>>>>>> - The second one is related to OpenGL and it seems to be caused 
>>>>>> by the
>>>>>> merge with Qt 4.8.2.
>>>>>>
>>>>>> 1. Missing symbols problem: Android comes with almost no support 
>>>>>> for
>>>>>> C++, so to compile Qt we used (static) gnu-libstdc++.
>>>>>> Then I discovered that this was a big mistake (for more 
>>>>>> information
>>>>>> check Android NDK docs/CPLUSPLUS-SUPPORT.html "II.3. Static 
>>>>>> runtimes:"
>>>>>> section).
>>>>>> We can not use link libstdc++ statically if we are using more 
>>>>>> than one
>>>>>> shared libraries in a project. To fix this problem I had two 
>>>>>> choices:
>>>>>>   - to use the shared libstdc++ implementation and to change all 
>>>>>> the
>>>>>> scripts in order to add it to ministro (1.2M).
>>>>>>   - to "embed" the whole library into QtCore library (it adds 
>>>>>> and extra
>>>>>> 600K) but this change requires no additional changes.
>>>>>>
>>>>>> I choose the second one [1],[2] because it was safe and easy and
>>>>>> mostly because it didn't needed any other changes.
>>>>>> If anybody has something against this change speak now or 
>>>>>> forever hold
>>>>>> your peace !
>>>>>>
>>>>>> I'd like to add exceptions and RTTI by default, if the size and 
>>>>>> speed
>>>>>> will not be affected.
>>>>>>
>>>>>> 2. OpenGL problem: After I merged alpha4 branch with upstream Qt
>>>>>> 4.8.2, most of the OpenGL apps are not working anymore, I tried 
>>>>>> to fix
>>>>>> it my self but I end up with a very ugly workarround. It seems 
>>>>>> that
>>>>>>
>>>>>> 
>>>>>> "boolQGLContext::areSharing(constQGLContext*context1,constQGLContext*contex
>>>>>> t2)"
>>>>>> always returns false. I tried to trace the problem but with no 
>>>>>> luck
>>>>>> and I end up adding a super dirty workarround: on android,
>>>>>> "QGLContext::areSharing", will always returns true. I really 
>>>>>> don't
>>>>>> like it, so until we'll figure out what is wrong the release 
>>>>>> process
>>>>>> will stop ...
>>>>>>
>>>>>> Any help will on this matter be very appreciated !
>>>>>>
>>>>>> I've spot another minor problem with old assets support it was 
>>>>>> caused
>>>>>> by "QString QDeclarativeTypeLoader::absoluteFilePath(const 
>>>>>> QString
>>>>>> &path)" I fixed it locally but I didn't had time to push the fix 
>>>>>> to
>>>>>> Minsitro's repository yet.
>>>>>> I'll keep you post with the progress and with any Ministro 
>>>>>> repository
>>>>>> changes.
>>>>>>
>>>>>> Cheers,
>>>>>> BogDan.
>>>>>>
>>>>>>
>>>>>> 
>>>>>> [1]http://quickgit.kde.org/index.php?p=android-qt.git&a=commit&h=8c4c862...
>>>>>>
>>>>>> 
>>>>>> [2]http://quickgit.kde.org/index.php?p=android-qt.git&a=commit&h=abe85f4...
>>>
>> _______________________________________________
>> Necessitas-devel mailing list
>> Necessitas-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/necessitas-devel
>
> _______________________________________________
> Necessitas-devel mailing list
> Necessitas-devel at kde.org
> https://mail.kde.org/mailman/listinfo/necessitas-devel

-- 
Willy Gardiol
willy at gardiol.org
www.gardiol.org
www.trackaway.org -> Track YOUR way the way you want!

More information about the Necessitas-devel mailing list