Alpha4 release status

BogDan bog_dan_ro at yahoo.com
Mon Jun 11 16:29:06 UTC 2012 

Hi Willy,

> 
> 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!
> 

This is also our goal !

>
> 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.
> 

Why alpha2 is _more_ usable than alpha3? What alpha2 has and is not in the alpha3? 
What are the problems with ICS?

>
> 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?
> 
AH, sorry, it wasn't my intention to start donation/founding campaign :), and if it looks 
like one, I apologize. Of course if anybody wants to contribute, I'm not going to refuse :-P.

Cheers,
BogDan.

> 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!
> _______________________________________________
> Necessitas-devel mailing list
> Necessitas-devel at kde.org
> https://mail.kde.org/mailman/listinfo/necessitas-devel
>

More information about the Necessitas-devel mailing list