Re: [Development] Reviews needed before android integration in two weeks
On quarta-feira, 6 de fevereiro de 2013 22.54.45, Olivier Goffart wrote: > > factors. Namely: > > - wakeUp() is only called from qcoreapplication.cpp with the event queue > > > >mutex locked > > wakeUp is called from many places, and without the lock. It's called from: - QCoreApplication::postEvent (locked) - QCoreApplicationPrivate::sendPostedEvents (locked) - QEventDispatcherUNIX::interrupt (called only from QEventLoop::exit) - QEventLoop::wakeUp - QObjectPrivate::setThreadData_helper (locked) - QWindowSystemInterfacePrivate::handleWindowSystemEvent (has a lock) Both QEventLoop::exit and QEventLoop::wakeUp do not need a lock, since they aren't changing the event queue. In QWindowSystemInterfacePrivate::handleWindowSystemEvent, the event queue is locked, but the lock is dropped before calling wakeUp. > It seems to be called from QCoreApplicationPrivate::sendPostedEvents with > the mutex locked, but that is a bug. We should unlock that mutex before > calling wakeUp, as wakeUp is user code and should not be called with the > mutex hold. That is true, but I'd argue that anyone implementing an event dispatcher is expert enough to deal with those issues. I'd just document that the function may be called with locked mutexes. Still, this is not a factor in the analysis. The next two guarantees are the important ones: > > - it's only called *after* the event queue has been modified in postEvent > > - processThreadWakeUp is only called *before* the event queue is > > inspected > Maybe there are other events? integration with a non-Qt event loop? That's what I said about the problem lying elsewhere. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Wednesday 06 February 2013 12:38:12 Thiago Macieira wrote: > On quarta-feira, 6 de fevereiro de 2013 21.13.36, Olivier Goffart wrote: > > That said, it is probably a good idea not to call select at all when it is > > not needed. But with that patch, you also make calls to write even when > > it is not needed, while before there was only call to write. > > The atomic is there to avoid a write to the pipe/eventfd when it has already > been written to. That is, in QEventDispatcherUNIX::wakeUp, it saves a > syscall if the target thread has already been told to wake up. > > In QEventDispatcherUNIXPrivate::processThreadWakeUp, it will read from the > pipe/eventfd and then reset the atomic back to zero, indicating that a write > is necessary again. > > Here's how an event is posted (thread A is the thread that does dispatching, > thread B is the one posting the event): > > - thread A is awake in QEventDispatcherUNIXPrivate::processThreadWakeUp > - thread B is in QEventDispatcherUNIX::wakeUp > - thread A has just returned from read(2) but hasn't reset the atomic yet > - (1) thread B is checking the atomic and finds it at 1 > - (2) thread A resets the atomic > - thread B will then proceed without writing to the eventfd/pipe > > All events in a given thread happen in the order that they are listed. > Events in separate threads can happen in any order relative to each other, > *except* for (1) and (2): must happen in that order because the reverse is > not possible. > > The above could be a problem, but isn't because it depends on external > factors. Namely: > > - wakeUp() is only called from qcoreapplication.cpp with the event queue >mutex locked wakeUp is called from many places, and without the lock. It seems to be called from QCoreApplicationPrivate::sendPostedEvents with the mutex locked, but that is a bug. We should unlock that mutex before calling wakeUp, as wakeUp is user code and should not be called with the mutex hold. > - it's only called *after* the event queue has been modified in postEvent > - processThreadWakeUp is only called *before* the event queue is inspected Yes, and that should garentee that QEvent get properly processed and that there is no race condition. > That means these two events are necessarily ordered: > > - thread B adds an event to thread A's event queue >[happens before "thread B is in QEventDispatcherUnix::wakeUp", > which happens before "thread B is checking the atomic and finds it at > 1"] - thread A processes its event queue >[happens after "thread A resets the atomic"] > > This proves that the event posting is correct. Empirical evidence (namely, > the lack of bug reports concerning this problem) also supports that > conclusion. > > If you're finding a problem, its root cause must be elsewhere and must be > dealt there. Maybe there are other events? integration with a non-Qt event loop? -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On quarta-feira, 6 de fevereiro de 2013 21.13.36, Olivier Goffart wrote: > That said, it is probably a good idea not to call select at all when it is > not needed. But with that patch, you also make calls to write even when > it is not needed, while before there was only call to write. The atomic is there to avoid a write to the pipe/eventfd when it has already been written to. That is, in QEventDispatcherUNIX::wakeUp, it saves a syscall if the target thread has already been told to wake up. In QEventDispatcherUNIXPrivate::processThreadWakeUp, it will read from the pipe/eventfd and then reset the atomic back to zero, indicating that a write is necessary again. Here's how an event is posted (thread A is the thread that does dispatching, thread B is the one posting the event): - thread A is awake in QEventDispatcherUNIXPrivate::processThreadWakeUp - thread B is in QEventDispatcherUNIX::wakeUp - thread A has just returned from read(2) but hasn't reset the atomic yet - (1) thread B is checking the atomic and finds it at 1 - (2) thread A resets the atomic - thread B will then proceed without writing to the eventfd/pipe All events in a given thread happen in the order that they are listed. Events in separate threads can happen in any order relative to each other, *except* for (1) and (2): must happen in that order because the reverse is not possible. The above could be a problem, but isn't because it depends on external factors. Namely: - wakeUp() is only called from qcoreapplication.cpp with the event queue mutex locked - it's only called *after* the event queue has been modified in postEvent - processThreadWakeUp is only called *before* the event queue is inspected That means these two events are necessarily ordered: - thread B adds an event to thread A's event queue [happens before "thread B is in QEventDispatcherUnix::wakeUp", which happens before "thread B is checking the atomic and finds it at 1"] - thread A processes its event queue [happens after "thread A resets the atomic"] This proves that the event posting is correct. Empirical evidence (namely, the lack of bug reports concerning this problem) also supports that conclusion. If you're finding a problem, its root cause must be elsewhere and must be dealt there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
About https://codereview.qt-project.org/46798 On Wednesday 06 February 2013 11:51:17 BogDan wrote: > I think I understood how the event loop is supposed to work, sadly, at least > on android, it doesn't work as it should. Is very simple to check it, just > revert that patch and test an UI application that doesn't have any active > timer, you should see the missing events immediately when you tap on the > device (push a button or something). I didn't said is a deadlock, what > I'm trying to say is that the event loop doesn't wake up immediately. But why is select blocking if there is something to read on that file descriptor? Normally, select should return immediatly in that case. That said, it is probably a good idea not to call select at all when it is not needed. But with that patch, you also make calls to write even when it is not needed, while before there was only call to write. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On quarta-feira, 6 de fevereiro de 2013 11.51.17, BogDan wrote: > I think I understood how the event loop is supposed to work, sadly, at least > on android, it doesn't work as it should. Is very simple to check it, just > revert that patch and test an UI application that doesn't have any active > timer, you should see the missing events immediately when you tap on the > device (push a button or something). I didn't said is a deadlock, what > I'm trying to say is that the event loop doesn't wake up immediately. Like I said, I don't doubt you found a problem. However, I think you're mis-diagnosing the problem. You said the events come from another thread. Is that a regular postEvent? If it isn't, the code that is inserting the events might be the problem and, thus, the fix should be there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
>> On Android all events are coming from another thread, and some time a few >> events are not delivered by the event loop. It happens because if an event >> is added to the event loop when the event loop just started to >> process/deliver the events this event is not sent because the event loop >> "goes to sleep" (calls the QEventDispatcherUNIX::select(...) > function), my >> patch prevents the call of select function if a new event was just added. > > That explanation is not specific to Android. It looks like a real case for > any > postEvent. Therefore, this change -- as described -- must be in QtCore or > nowhere at all. > > However, your explanation is either mistaken or incomplete. The select() call > will not sleep because the pipe or eventfd will have unread data: instead, it > will wake up immediately. Then the event dispatcher will realise that there > are more events in the queue and will proceed to dispatch them. > > I don't doubt that you found a deadlock condition somehow. But I am not > convinced that you understood it correctly or that you fixed it properly. > I think I understood how the event loop is supposed to work, sadly, at least on android, it doesn't work as it should. Is very simple to check it, just revert that patch and test an UI application that doesn't have any active timer, you should see the missing events immediately when you tap on the device (push a button or something). I didn't said is a deadlock, what I'm trying to say is that the event loop doesn't wake up immediately. BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On quarta-feira, 6 de fevereiro de 2013 10.23.25, BogDan wrote: > On Android all events are coming from another thread, and some time a few > events are not delivered by the event loop. It happens because if an event > is added to the event loop when the event loop just started to > process/deliver the events this event is not sent because the event loop > "goes to sleep" (calls the QEventDispatcherUNIX::select(...) function), my > patch prevents the call of select function if a new event was just added. That explanation is not specific to Android. It looks like a real case for any postEvent. Therefore, this change -- as described -- must be in QtCore or nowhere at all. However, your explanation is either mistaken or incomplete. The select() call will not sleep because the pipe or eventfd will have unread data: instead, it will wake up immediately. Then the event dispatcher will realise that there are more events in the queue and will proceed to dispatch them. I don't doubt that you found a deadlock condition somehow. But I am not convinced that you understood it correctly or that you fixed it properly. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
[...] >> >> M src/corelib/kernel/qeventdispatcher_unix.cpp >> >> M src/corelib/kernel/qeventdispatcher_unix_p.h >> > >> > This one needs a very good explanation. >> >> Would you mind discussing this with Bogdan on >> >> https://codereview.qt-project.org/#change,46798 >> >> Apparently it was needed to fix a deadlock in the event loop on Android. >> It was suggested that we move the hacky implementation into the android >> plugin instead. Would that be an acceptable solution, at least for a >> first go? > > It needs a good explanation or it should not be added at all. With all due > respect to Bogdan, I cannot rule out that he made a mistake in interpreting > the situation. > On Android all events are coming from another thread, and some time a few events are not delivered by the event loop. It happens because if an event is added to the event loop when the event loop just started to process/deliver the events this event is not sent because the event loop "goes to sleep" (calls the QEventDispatcherUNIX::select(...) function), my patch prevents the call of select function if a new event was just added. BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On quarta-feira, 6 de fevereiro de 2013 11.07.44, Eskil Abrahamsen Blomfeldt wrote: > >> A lib/rules.xml > > > > I'd rather you found a better place for this file. > > I was planning on putting it into src/android and having it deployed > into lib/rules.xml when you build for Android. > > Would that be acceptable? I'd like to deploy it in lib/ because then the > Qt Creator plugin doesn't need to look in two different places for the > file for Qt 4 and Qt 5 builds. You install it where it needs to be installed. But the source doesn't need to be in lib, especially considering out-of-source builds. > >> A mkspecs/features/java.prf > > > > Ossi to judge if the mkpath should be there. > > Ossi wrote the code ;) > > > javac.depends looks like a horrible hack. In fact, while this is a nice > > feature, the whole file looks like a hack. qmake should be modified to > > learn how to compile Java instead. > > I disagree. The fewer hardcoded things we have in qmake, the better in > my opinion. I do agree that the LINK override is hacky, but at least > it's a working solution with the current system and the cleanest we > could think of. If qmake is changed later to add a less hacky way to > override the different compile steps, I'll be glad to adapt to it, but > for now, I'd like to keep this build system and focus on more pressing > things before the feature freeze :) In the long run, I'd like to see if qmake understood how to compile *.java when listed in SOURCES. Then again, if I think a little more about this subject, no, I don't want that. Adding features to qmake is a bad idea. We should be looking for a better buildsystem instead, so devoting our buildsystem efforts to that direction is preferred. This solution above is just fine. > > . Also, doesn't qpa/android.prf conflict with android.prf? > > I don't know. I haven't seen any issues. But I don't know if > qpa/android.prf is actually used for anything. Then drop it. > >> M src/corelib/kernel/qeventdispatcher_unix.cpp > >> M src/corelib/kernel/qeventdispatcher_unix_p.h > > > > This one needs a very good explanation. > > Would you mind discussing this with Bogdan on > > https://codereview.qt-project.org/#change,46798 > > Apparently it was needed to fix a deadlock in the event loop on Android. > It was suggested that we move the hacky implementation into the android > plugin instead. Would that be an acceptable solution, at least for a > first go? It needs a good explanation or it should not be added at all. With all due respect to Bogdan, I cannot rule out that he made a mistake in interpreting the situation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On quarta-feira, 6 de fevereiro de 2013 16.45.15, Eskil Abrahamsen Blomfeldt wrote: > On 02/06/2013 04:43 PM, Thiago Macieira wrote: > > Note: a way out is to define *both*. > > This sounds like a logical compromise to me. We can define the > Q_OS_LINUX_ANDROID and document that it's to avoid breaking existing > code, and we can use Q_OS_ANDROID internally in Qt. Please choose one of: 1) deprecate Q_OS_LINUX_ANDROID and document Q_OS_ANDROID as the preferred 2) document both as equivalents, like Q_OS_DARWIN and Q_OS_MAC -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On 02/06/2013 04:43 PM, Thiago Macieira wrote: > Note: a way out is to define *both*. This sounds like a logical compromise to me. We can define the Q_OS_LINUX_ANDROID and document that it's to avoid breaking existing code, and we can use Q_OS_ANDROID internally in Qt. -- Eskil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On quarta-feira, 6 de fevereiro de 2013 00.40.45, BogDan wrote: > When, where, who ? > > I changed that macro because Google[1] and GCC[2] consider that the name of > the O.S. is ANDROID not LINUX-ANDROID and they define a preprocessor macro > as __ANDROID__ (not __LINUX_ANDROID__)! Because Q_OS_ is referring to the > OS not to the kernel I found it naturally to call it simple Q_OS_ANDROID > not Q_OS_LINUX_ANDROID (just like you folks did with Q_OS_MAC, Q_OS_CYGWIN, > etc). > > Anyway this is my last reaction on this matter, because I'm finding it a > little bit childish and never ending, is like a discussion between Linus > and Richard on Linux vs GNU/Linux matter. If not even GCC and Google don't > convince that ANDROID is the right name (and not LINUX_ANDROID), then for > me will be impossible to do it I understand your reasoning. And I can't fault it. However, now this is no longer about "which one is the best name" but instead about changing what we already currently have. Qt 5.0.0 shipped with Q_OS_LINUX_ANDROID (though unsupported). So your argument about which one is best, is fine. But you need also to argue about why we need to change about what has been shipped. Note: a way out is to define *both*. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
Hi, On Wednesday 06 February 2013 13:05:33 Paul Olav Tvete wrote: > On Wednesday 6 February 2013 09:41:46 Paul Olav Tvete wrote: > > On Wednesday 6 February 2013 09:00:41 Thomas McGuire wrote: > > > A workaround would be to squash all commits of the branch together into > > > a single patch and then upload that to Gerrit for review. Now, > > > actually pushing the single patch would lose history, so we'd instead > > > manually do a > > > proper merge of the branch. How about we do that for the Android merge? > > > > That's a great idea! We can push a squashed commit as a WIP to gerrit. I > > think we should do a preliminary one this week. (And yes, this is a "we > > should" that means "I will" in the old Trolltech tradition :) > > Here is a squashed commit of all changes to qtbase, for those who like to > see everything in one place: > https://codereview.qt-project.org/#change,46976 > > qtdeclarative: https://codereview.qt-project.org/#change,46983 > qtsensors: https://codereview.qt-project.org/#change,46984 Thanks, that is quite helpful. Discovered some more things during the review on Gerrit. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Wednesday 6 February 2013 09:41:46 Paul Olav Tvete wrote: > On Wednesday 6 February 2013 09:00:41 Thomas McGuire wrote: > > A workaround would be to squash all commits of the branch together into a > > single patch and then upload that to Gerrit for review. Now, actually > > pushing the single patch would lose history, so we'd instead manually do > > a > > proper merge of the branch. How about we do that for the Android merge? > > That's a great idea! We can push a squashed commit as a WIP to gerrit. I > think we should do a preliminary one this week. (And yes, this is a "we > should" that means "I will" in the old Trolltech tradition :) Here is a squashed commit of all changes to qtbase, for those who like to see everything in one place: https://codereview.qt-project.org/#change,46976 qtdeclarative: https://codereview.qt-project.org/#change,46983 qtsensors: https://codereview.qt-project.org/#change,46984 - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Tue, Feb 05, 2013 at 12:16:26PM -0800, BogDan wrote: > Android has almost none of the previous libraries and utilities. > > Even distrowatch consider android a different O.S. > http://distrowatch.com/dwres.php?resource=links#otheros > it basically boils down to what is more likely to be used as a condition in project files. linux including or excluding android? this leads to the two options: linux|android: FOO = bar# decided on userspace, but kernel matters and linux:!android: BAZ = knolf# decided on kernel, but userspace matters note that i'm using the new platform scopes instead of the spec name matching. which scopes should be defined is part of the same decision. the assumption so far was "android linux unix posix". but follwing your argumentation, one has to wonder whether it's even unix? maybe it's only "android posix"? (no, not really. "android unix posix" at least). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Wed, Feb 06, 2013 at 09:41:46AM +0100, Paul Olav Tvete wrote: > On Wednesday 6 February 2013 09:00:41 Thomas McGuire wrote: > > A workaround would be to squash all commits of the branch together into a > > single patch and then upload that to Gerrit for review. Now, actually > > pushing the single patch would lose history, so we'd instead manually do a > > proper merge of the branch. How about we do that for the Android merge? > > That's a great idea! We can push a squashed commit as a WIP to gerrit. > this is a possible workaround for gerrit's failure to display diffs for merges, yes. but then, the approach is all wrong anyway. the basic assumption for mergable branches is that every single commit in them follows all applicable policies and got proper review (by the respective experts/maintainers). this is so totally *not* the case for the android branch. consequently, eskil already started doing the right thing: extracting atomic changes and submitting them straight for dev. this is how the ios and winrt branches are supposed to be handled as well. that makes these branches throw-away branches, which permits relaxing the policies. optionally, rebase the branch on top of dev and continue, possibly repeatedly. this would have the advantage or reduced duplication of work - ios and android have many of the same requirements in the build system area, for example. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
Thanks for the comments. I'll convert them all into tasks or add them as comments in Gerrit if the patches in question are already in there. On 02/06/2013 03:04 AM, Thiago Macieira wrote: > -2 on the -openssl-source option. It's not used anywhere. Yes, that's a left-over. I'll remove it. >> A lib/rules.xml > I'd rather you found a better place for this file. I was planning on putting it into src/android and having it deployed into lib/rules.xml when you build for Android. Would that be acceptable? I'd like to deploy it in lib/ because then the Qt Creator plugin doesn't need to look in two different places for the file for Qt 4 and Qt 5 builds. > . >> A mkspecs/features/java.prf > Ossi to judge if the mkpath should be there. Ossi wrote the code ;) > > javac.depends looks like a horrible hack. In fact, while this is a nice > feature, the whole file looks like a hack. qmake should be modified to learn > how > to compile Java instead. I disagree. The fewer hardcoded things we have in qmake, the better in my opinion. I do agree that the LINK override is hacky, but at least it's a working solution with the current system and the cleanest we could think of. If qmake is changed later to add a less hacky way to override the different compile steps, I'll be glad to adapt to it, but for now, I'd like to keep this build system and focus on more pressing things before the feature freeze :) > . Also, doesn't qpa/android.prf conflict with android.prf? I don't know. I haven't seen any issues. But I don't know if qpa/android.prf is actually used for anything. >> A src/android/... > I suggest the dir be renamed to src/androidmain, to match winmain and the old > (and thankfully removed) s60main. Ok, sounds good to me. > >> M src/corelib/kernel/qeventdispatcher_unix.cpp >> M src/corelib/kernel/qeventdispatcher_unix_p.h > This one needs a very good explanation. Would you mind discussing this with Bogdan on https://codereview.qt-project.org/#change,46798 Apparently it was needed to fix a deadlock in the event loop on Android. It was suggested that we move the hacky implementation into the android plugin instead. Would that be an acceptable solution, at least for a first go? > > M src/network/ssl/ssl.pri > -1: this unconditionally builds OpenSSL support in, even if the sources aren't > present. The configure script changes required for this aren't correct. I've already reverted the changes in SSL.pri. I'll remove the enablers from configure as well. > . > >> A src/widgets/styles/json/json.cpp >> A src/widgets/styles/json/json.g >> A src/widgets/styles/json/json.h >> A src/widgets/styles/json/json.pri >> A src/widgets/styles/json/jsonparser.cpp > -1. Do not add. > > You need to show that this is at least 5x faster than the one in QtCore before > this begins to be acceptable. > > I'm not the QtWidgets maintainer. If I were, I'd be giving a -2. Yes, I'll remove these and rewrite to use Qt's json parser. -- Eskil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Wednesday 6 February 2013 09:00:41 Thomas McGuire wrote: > A workaround would be to squash all commits of the branch together into a > single patch and then upload that to Gerrit for review. Now, actually > pushing the single patch would lose history, so we'd instead manually do a > proper merge of the branch. How about we do that for the Android merge? That's a great idea! We can push a squashed commit as a WIP to gerrit. I think we should do a preliminary one this week. (And yes, this is a "we should" that means "I will" in the old Trolltech tradition :) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
[...] >> M src/corelib/codecs/qtextcodec.cpp >> M src/corelib/codecs/qtextcodec_p.h > > This has been discussed before. Please leave the macro called > Q_OS_LINUX_ANDROID. > When, where, who ? I changed that macro because Google[1] and GCC[2] consider that the name of the O.S. is ANDROID not LINUX-ANDROID and they define a preprocessor macro as __ANDROID__ (not __LINUX_ANDROID__)! Because Q_OS_ is referring to the OS not to the kernel I found it naturally to call it simple Q_OS_ANDROID not Q_OS_LINUX_ANDROID (just like you folks did with Q_OS_MAC, Q_OS_CYGWIN, etc). Anyway this is my last reaction on this matter, because I'm finding it a little bit childish and never ending, is like a discussion between Linus and Richard on Linux vs GNU/Linux matter. If not even GCC and Google don't convince that *ANDROID* is the right name (and not LINUX_ANDROID), then for me will be impossible to do it :) [...] [1] https://android.googlesource.com/platform/prebuilts/ndk/+/master/8/platforms/android-14/arch-arm/usr/include/EGL/eglplatform.h [2] http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/GNU_002fLinux-Options.html#GNU_002fLinux-Options Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
Hi, On Tuesday 05 February 2013 14:22:47 Thomas McGuire wrote: > On Tuesday 05 February 2013 11:33:29 Paul Olav Tvete wrote: > > One of the major features for Qt 5.1 is Android support. We have been > > doing the work in a feature branch, and are now getting ready to > > integrate to the dev branch. To beat the rush of integrations before > > feature freeze, we aim to start the integration in two weeks time. > > > > Most of the changes are android-specific, but there are a few changes > > touching cross-platform code. To make the integration go smootly, we ask > > approvers and maintainers to check the android changes in their areas > > now, so we can fix any problems before the merge. To see the changes, > > check out (or diff against) the "wip/android" branch. > > > > I have appended a list of changed files for the following repositories: > > qtsensors > > Another thing: [...] And another one: Please add the Android platform to the compatibility table in the docs, which shows what sensors are available for each platform. It is the file src/sensors/doc/src/compatmap.qdoc. Also, if there are any Android- specific gotchas, they should go to the "Platform-specific Information" section in qtsensors.doc. As I side note, I find this reviewing-by-email quite inconvenient. It doesn't give anyone the chance to -1 properly, and comments per email are less than convenient. All this increases the risk of changes getting merged without a proper review, and consequently is bad for the quality of Qt at large. I expect we'll have the same kind of issues when we merge other branches like the winrt one. A github-style review of the complete branch before merging would really be nice and solve all these issues. I guess this is not yet supported by Gerrit? A workaround would be to squash all commits of the branch together into a single patch and then upload that to Gerrit for review. Now, actually pushing the single patch would lose history, so we'd instead manually do a proper merge of the branch. How about we do that for the Android merge? Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On terça-feira, 5 de fevereiro de 2013 11.33.29, Paul Olav Tvete wrote: > M config.tests/qpa/linuxfb/linuxfb.cpp > M config.tests/unix/arch.test +2 up to here. > M config.tests/unix/compile.test This one has superfluous changes. It sets a QMAKE variable that is not used anywhere. > M config.tests/unix/evdev/evdev.cpp > M config.tests/unix/getaddrinfo/getaddrinfotest.cpp +2 And +ugh! on the getaddrinfotest.cpp. Recheck if it's necessary. Drop if it's not. > A config.tests/unix/ipc_android/ipc.cpp > A config.tests/unix/ipc_android/ipc_android.pro Questionable copyright on the .cpp file. Looks like it's checking for linux/ashmem.h and some macros. > M config.tests/unix/makeabs +1. It's about cross-compilation from windows to unix. > M configure +1 on the msys part, but I can't approve. -1 on the detection of android. It detects android via one single mkspec name, which is hardcoded. This should be done by a getQMakeConf call and extracting a variable set there, if necessary. Or by a compile test, like the ashmem above. -1 on the unnecessary whitespace changes. Except that I can't find where they were introduced... might be an artifact of my diff. -1 on this: +if [ "$PLATFORM" = "win32-g++" ] || [ "$XPLATFORM" = "win32-g++" ] && [ "$CFG_MS_BITFIELDS" = "yes" ]; then +QMAKE_CONFIG="$QMAKE_CONFIG ms_bitfields" +fi The above enables ms_bitfields unconditionally for MinGW, regardless of cross- compilation or anything else. You're missing parentheses. -2 on the -openssl-source option. It's not used anywhere. > A lib/rules.xml I'd rather you found a better place for this file. > A mkspecs/android-g++/qmake.conf -1 on CONFIG += ashmem. It looks wrong. -2 on QT = android. You can't have "android" there, period. That belongs to a library called QtAndroid, if and when that exists, and it MUST NOT be default. If you need that for initialisation, figure out like qtmain / winmain does. Just don't touch the QT variable. The file has some weird indentation. -1 on setting -g on the release flags. This produces an unlinkable QtWebKit. > A mkspecs/android-g++/qplatformdefs.h > D mkspecs/common/android/qplatformdefs.h > D mkspecs/common/linux-android.conf Please keep the common files. > A mkspecs/features/android.prf Copyright header is out of style. Please use one in our format. > A mkspecs/features/java.prf Ossi to judge if the mkpath should be there. javac.depends looks like a horrible hack. In fact, while this is a nice feature, the whole file looks like a hack. qmake should be modified to learn how to compile Java instead. > M mkspecs/features/moc.prf -1. The change looks wrong. It needs justification. > A mkspecs/features/qpa/android.prf $$[QT_INSTALL_PREFIX]/src makes no sense. Please choose another path. Also, doesn't qpa/android.prf conflict with android.prf? > M mkspecs/features/qpa/genericunixfontdatabase.prf -1 on coding style. > M mkspecs/features/qt_functions.prf -2 for reasons explained above. Do not modify the QT variable. > M mkspecs/features/qt_parts.prf Changes look incorrect at first glance. Ossi to judge. > M mkspecs/features/resources.prf As the comment says, proper investigation should be done. If it weren't for the comment, I'd have given +2. > M mkspecs/features/static.prf There's no linux-mingw-*. I'd like to see this made more generic: add a variable to the qmake.conf instead. I can then add -static-intel for icc, for example. > D mkspecs/unsupported/linux-android-armeabi-g++/qmake.conf > D mkspecs/unsupported/linux-android-armeabi-g++/qplatformdefs.h > D mkspecs/unsupported/linux-android-armeabi-v7a-g++/qmake.conf > D mkspecs/unsupported/linux-android-armeabi-v7a-g++/qplatformdefs.h > D mkspecs/unsupported/linux-android-x86-g++/qmake.conf > D mkspecs/unsupported/linux-android-x86-g++/qplatformdefs.h Ok, it's supported now. +2 > M qmake/generators/makefile.cpp > M qmake/generators/unix/unixmake2.cpp > M qmake/generators/win32/mingw_make.cpp > M qmake/generators/win32/msvc_nmake.cpp Part of the make-qmake-understand-Java, but incomplete. See above. > M qtbase.pro Unnecessary change. > A src/android/... I suggest the dir be renamed to src/androidmain, to match winmain and the old (and thankfully removed) s60main. > M src/corelib/arch/arch.pri > A src/corelib/arch/qatomic_android.h -1. Looks superfluous. It's doing exactly what qbasicatomic.h is already doing. Please justify. > M src/corelib/codecs/qiconvcodec.cpp +2 > M src/corelib/codecs/qiconvcodec_p.h +1 but Q_OS_WIN && Q_CC_GNU. > M src/corelib/codecs/qtextcodec.cpp > M src/corelib/codecs/qtextcodec_p.h This has been discussed before. Please leave the macro called Q_OS_LINUX_ANDROID. >From this point on, any +2 does is modulo the macro name b
Re: [Development] Reviews needed before android integration in two weeks
I agreed with Simon's initial pragmatic heads up which was that: linux* blocks in existing qmake profile files would probably want be the primary code path you would want to be followed in/under Android, in the initial compilation/porting to Android. It wasn't an attempt at bike shedding. The Qt mkspecs have goofy names; All the linux-foo mkspecs are more indicative of the toolchain/userspace in use than the kernel. http://en.wikipedia.org/wiki/Bionic_(software) Let me paraphrase since I don't know shit: "Bionic has several major Linux-specific features and development continues independent of other code bases" So I would kind of expect any android specific code/implementations to most resemble Linux, rather than the Windows/Mac/symbian implementations. If Android adopts the Linux naming scheme, the Linux impls will be grabbed at the baseline, which I assume would be desired default behavior unless you explicitly specialize off of this. If you people know better, and god I hope you do, then merrily override this. Just my 2p, Donald On Tue, Feb 5, 2013 at 1:15 PM, Keith Gardner wrote: > [snip] > According to: > http://en.wikipedia.org/wiki/Android_(operating_system) > "Android is a Linux-based operating system ..." > but on the same page says: > "Android does not have a native X Window System by default nor does it > support the full set of standard GNU libraries, and this makes it difficult > to port existing Linux applications or libraries to Android." > > > According to Qt's wiki page "Licensing Talk about Mobile Platforms," Android > is defined as the following: > > "The Google Android operating system is based on Embedded Linux. Therefore it > is permitted as an application deployment platform, as long as the developer > has an "Embedded Linux" license." > > http://qt-project.org/wiki/Licensing-talk-about-mobile-platforms > > To point out, this decision has implications on licensing Qt. > > Keith > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
[snip] According to: http://en.wikipedia.org/wiki/Android_(operating_system) "Android is a Linux-based operating system ..." but on the same page says: "Android does not have a native X Window System by default nor does it support the full set of standard GNU libraries, and this makes it difficult to port existing Linux applications or libraries to Android." According to Qt's wiki page "Licensing Talk about Mobile Platforms," Android is defined as the following: "The Google Android operating system is based on Embedded Linux. Therefore it is permitted as an application deployment platform, as long as the developer has an "Embedded Linux" license." http://qt-project.org/wiki/Licensing-talk-about-mobile-platforms To point out, this decision has implications on licensing Qt. Keith ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
> > > 05.02.2013, 16:10, "Eskil Abrahamsen Blomfeldt" > : >> Technically I don't think Android is considered a Linux-distribution. > > http://en.wikipedia.org/wiki/Linux_distribution > > "A Linux distribution ... is a member of the family of Unix-like operating > systems built on top of the Linux kernel." > > Android is certainly Unix-like and built on top of the Linux kernel, so > technically it *is* a Linux-distribution. There is more on http://en.wikipedia.org/wiki/Linux_distribution "Such distributions are operating systems including a large collection of software applications such as word processors, spreadsheets, media players, and database applications. These operating systems consist of the Linux kernel and, usually, a set of libraries and utilities from the GNU Project, with graphics support from the X Window System. ..." Android has almost none of the previous libraries and utilities. Even distrowatch consider android a different O.S. http://distrowatch.com/dwres.php?resource=links#otheros and even wikipedia don't list android here: http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions According to: http://en.wikipedia.org/wiki/Android_(operating_system) "Android is a Linux-based operating system ..." but on the same page says: "Android does not have a native X Window System by default nor does it support the full set of standard GNU libraries, and this makes it difficult to port existing Linux applications or libraries to Android." and the examples can continue: http://arstechnica.com/gadgets/2009/02/an-introduction-to-google-android-for-developers/ BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
05.02.2013, 16:10, "Eskil Abrahamsen Blomfeldt" : > Technically I don't think Android is considered a Linux-distribution. http://en.wikipedia.org/wiki/Linux_distribution "A Linux distribution ... is a member of the family of Unix-like operating systems built on top of the Linux kernel." Android is certainly Unix-like and built on top of the Linux kernel, so technically it *is* a Linux-distribution. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On terça-feira, 5 de fevereiro de 2013 13.10.21, Eskil Abrahamsen Blomfeldt wrote: > Technically I don't think Android is considered a Linux-distribution. > Wouldn't this be similar to renaming the OSX mkspec to "macx-g++-darwin"? darwin-g++-aqua -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On 02/06/2013 04:07 AM, Laszlo Papp wrote: On Tue, Feb 5, 2013 at 6:00 PM, Jake Thomas Petroules mailto:jake.petrou...@petroules.com>> wrote: Surely you meant darwin-g++-macx. :) I don't think the Android mkspec warrants having Linux in it simply because it's such a radically different system in many ways. Custom C++ library, different executable format, custom packaging tools, custom UI stack, the fact that native apps can't even be run standalone without Java glue (at least before 2.3)... Linux would refer to the kernel just like in case of Maemo. It simply cannot refer to the UI stack, packaging tools, executable format, and what not as there is a good deal of permutation for those. In addition to the confusion about "linux-android-g++" working only on Linux host: one could say "android-g++" means Android works with any kernel type. :-) How about: it has only one kernel type and thus adding kernel type to the mkspec is pointless. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Tue, Feb 5, 2013 at 6:00 PM, Jake Thomas Petroules < jake.petrou...@petroules.com> wrote: > Surely you meant darwin-g++-macx. :) > > I don't think the Android mkspec warrants having Linux in it simply > because it's such a radically different system in many ways. Custom C++ > library, different executable format, custom packaging tools, custom UI > stack, the fact that native apps can't even be run standalone without Java > glue (at least before 2.3)... > Linux would refer to the kernel just like in case of Maemo. It simply cannot refer to the UI stack, packaging tools, executable format, and what not as there is a good deal of permutation for those. In addition to the confusion about "linux-android-g++" working only on Linux host: one could say "android-g++" means Android works with any kernel type. :-) Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
Surely you meant darwin-g++-macx. :) I don't think the Android mkspec warrants having Linux in it simply because it's such a radically different system in many ways. Custom C++ library, different executable format, custom packaging tools, custom UI stack, the fact that native apps can't even be run standalone without Java glue (at least before 2.3)... it's much further from Linux than Maemo is. As a comparison, BlackBerry's mkspec does not include QNX. Jake Petroules Petroules Corporation (www.petroules.com) Email: jake.petrou...@petroules.com Telephone: +1 (970) 587-3821 On Feb 5, 2013, at 7:10 AM, Eskil Abrahamsen Blomfeldt wrote: > On 02/05/2013 12:49 PM, Friedemann Kleint wrote: >> - Nokia is also mentioned along with names of former employees in the >> json style parser under widgets/styles. Btw, I am generally wondering >> about it, it seems to add a new Json parser. Could it be replaced by >> the Json classes of QtCore? > > We have a task about that. I think it either needs to be replaced by > Qt's json classes or put into 3rdparty. > >> >> - Compilation of the branch under Windows fails with the attached >> log. Something is probably wrong with #ifdefing/profiles? > > Great, thanks! > > Simon Hausmann wrote: >> Let's put it this way: linux-g++* is just as fuzzy as android-g++* in what it >> means. But we're not in the business of creating mathematical formulas, we're >> in the business of making life easier for software developers. If we can make >> it easier for people to port their app to Android, why don't we do it? > > I don't have any very strong opinion either way, so whatever the > majority decides is fine by me, but since there's a disagreement: Could > you please elaborate on what makes linux-android-g++ (or > linux-g++-android for symmetry with maemo) simpler for the developer > compared to android-g++? > > Technically I don't think Android is considered a Linux-distribution. > Wouldn't this be similar to renaming the OSX mkspec to "macx-g++-darwin"? > > -- Eskil > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
[..] > Simply put: Consistency. We do have linux-g++-maemo, linux-g++, linux-arm- > gnueabi-g++ > > They're all flavours of Linux, following the os-compiler/variant pattern. > There's no guarantee about what system libraries are in there. In that sense > I > feel Android is a variant of Linux. In the kernel sense Android is a > super-set > of the traditional Linux kernel mostly, isn't it? And it's moving closer > to > mainline step by step. > > Now after a closer inspection I do have to retract my argument with regards > to > the use of linux* in WebKit. Just disregard it ;) > > Consistency is the only argument that I can think of. It's not a strong one, > > so I won't go on and on about it. But please consider it :) > linux-g++-maemo, linux-g++, linux-arm-gnueabi-g++ are real linux distributions where I can expect to find linux specific libs, tools and apps (e.g. ssh, telnet, etc.), which is not the case for Android, except the linux kernel there is nothing "linux" in android ... On android you have less than 15 libs that you can use (+Qt ;-) ), linux-android IMHO it will be confusing for developers because for most of them linux is not just a kernel but the whole O.S. and they will start asking why the don't find libX if this is a linux. Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On 2/5/13 1:21 PM, "BogDan" wrote: >Hi, > >[...] >> - Nokia is also mentioned along with names of former employees in the >>json style > >> parser under widgets/styles. Btw, I am generally wondering about it, >>it seems >> to add a new Json parser. Could it be replaced by the Json classes of >>QtCore? >> > > last time when I tried Json classes of QtCore were much slower than the >"new" >json parser. Because every application that uses native look and feel >must parse >a json file every time when it starts, the parsing speed is a very >important factor. I did actually measure this, and if the other parser is the one from Girish, I am pretty sure the one in Qt Core is faster. In any case, I don't want to have another JSON parser in Qt Widgets. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On 02/05/2013 02:15 PM, David Faure wrote:
> .
> Looking at the patch with git diff origin/dev...origin/wip/android
> [not very convenient for commenting on code changes...]
>
> I see changes that are unrelated to android:
I've tried to separate the non-android-specific changes we inherited
from Necessitas out into separate commits that I will submit to dev
ahead of time and get proper reviews as soon as possible, as I think we
will might have to go a few rounds with some of them before they can be
approved.
Currently I have them as WIPs in Gerrit, because I'm waiting for help to
understand what each of them are doing. Once I do, I will update the
commit messages and add relevant people as reviewers for them.
Here's a list of the changes in question (you could also filter on my
name and look for anything starting with WIP:). The commit messages are
place holders at the moment, but if maintainers want to look at them
already, then I would glad to have feedback as soon as possible:
https://codereview.qt-project.org/#change,46789
https://codereview.qt-project.org/#change,46790
https://codereview.qt-project.org/#change,46791
https://codereview.qt-project.org/#change,46792
https://codereview.qt-project.org/#change,46793
https://codereview.qt-project.org/#change,46794 (this is also missing
documentation)
https://codereview.qt-project.org/#change,46795
https://codereview.qt-project.org/#change,46796
https://codereview.qt-project.org/#change,46797
https://codereview.qt-project.org/#change,46798
https://codereview.qt-project.org/#change,46800
https://codereview.qt-project.org/#change,46801
https://codereview.qt-project.org/#change,46802
https://codereview.qt-project.org/#change,46803
https://codereview.qt-project.org/#change,46804
https://codereview.qt-project.org/#change,46805
https://codereview.qt-project.org/#change,46806
> --- a/src/gui/kernel/qplatforminputcontext.cpp
> +++ b/src/gui/kernel/qplatforminputcontext.cpp
> @@ -114,7 +114,7 @@ void QPlatformInputContext::commit()
> /*!
> Notification on editor updates. Called by QInputMethod::update().
>*/
> -void QPlatformInputContext::update(Qt::InputMethodQueries)
> +void QPlatformInputContext::update(Qt::InputMethodQueries queries)
> {
> }
>
> Well, this is just bogus, it creates a compiler warning.
I'll remove stuff like this from the initial commit before submitting it
to dev.
-- Eskil
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Tuesday 05 February 2013 11:33:29 Paul Olav Tvete wrote: > One of the major features for Qt 5.1 is Android support. We have been > doing the work in a feature branch, and are now getting ready to > integrate to the dev branch. To beat the rush of integrations before > feature freeze, we aim to start the integration in two weeks time. > > Most of the changes are android-specific, but there are a few changes > touching cross-platform code. To make the integration go smootly, we ask > approvers and maintainers to check the android changes in their areas now, > so we can fix any problems before the merge. To see the changes, check out > (or diff against) the "wip/android" branch. > > I have appended a list of changed files for the following repositories: > qtsensors Another thing: I had a look at the diff, and saw that it renames the plugin interfaces from com.nokia to org.qt-project. However this change is incomplete, as it misses the examples, tests and doc snippets. I'd prefer if you revert that change in the branch. Lorn is already working on the same renaming at https://codereview.qt- project.org/#change,45288, and that patch seems to rename all instances. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Tuesday 05 February 2013 11:33:29 Paul Olav Tvete wrote:
> To see the changes, check out (or diff against) the
> "wip/android" branch.
Looking at the patch with git diff origin/dev...origin/wip/android
[not very convenient for commenting on code changes...]
I see changes that are unrelated to android:
--- a/src/corelib/codecs/qiconvcodec_p.h
+++ b/src/corelib/codecs/qiconvcodec_p.h
@@ -55,7 +55,7 @@
#include "qtextcodec.h"
-#if defined(Q_OS_UNIX) && !defined(QT_NO_ICONV) && !defined(QT_BOOTSTRAPPED)
+#if (defined(Q_OS_UNIX) || defined(__MINGW32__)) && !defined(QT_NO_ICONV) &&
!defined(QT_BOOTSTRAPPED)
#ifdef Q_OS_MAC
typedef void * iconv_t;
This adds MINGW !?
+if (d->goToSleep.testAndSetAcquire(1,1)) // don't go to bed if someone
just woked you up !
Typo :-) woked -> woke
--- a/src/gui/kernel/qplatforminputcontext.cpp
+++ b/src/gui/kernel/qplatforminputcontext.cpp
@@ -114,7 +114,7 @@ void QPlatformInputContext::commit()
/*!
Notification on editor updates. Called by QInputMethod::update().
*/
-void QPlatformInputContext::update(Qt::InputMethodQueries)
+void QPlatformInputContext::update(Qt::InputMethodQueries queries)
{
}
Well, this is just bogus, it creates a compiler warning.
--- a/src/widgets/widgets/qtextbrowser.cpp
+++ b/src/widgets/widgets/qtextbrowser.cpp
@@ -156,7 +156,12 @@ QString QTextBrowserPrivate::findFile(const QUrl &name)
const
else if (name.scheme().isEmpty())
fileName = name.path();
else
-fileName = name.toLocalFile();
+{
+if (name.scheme() == QLatin1String("assets"))
+fileName = QLatin1String("assets:") + name.path();
Urgh. This is a pretty broken way to construct a URL. Think of a path with a
'#' in it...
--- a/src/widgets/widgets/qabstractbutton.cpp
+++ b/src/widgets/widgets/qabstractbutton.cpp
@@ -1119,6 +1119,11 @@ void QAbstractButton::mouseReleaseEvent(QMouseEvent *e)
return;
}
+#ifdef Q_OS_ANDROID
+d->repeatTimer.stop();
+d->click();
+e->accept();
+#else
Urgh, I thought we didn't want OS-specific defines in widgets anymore, after the
whole QPA re-architecture. Didn't we get rid of such Q_WS_X11 hacks on purpose?
--
David Faure | david.fa...@kdab.com | Managing Director KDAB France
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
Hi, On Tuesday 05 February 2013 11:33:29 Paul Olav Tvete wrote: > One of the major features for Qt 5.1 is Android support. We have been > doing the work in a feature branch, and are now getting ready to > integrate to the dev branch. To beat the rush of integrations before > feature freeze, we aim to start the integration in two weeks time. > > Most of the changes are android-specific, but there are a few changes > touching cross-platform code. To make the integration go smootly, we ask > approvers and maintainers to check the android changes in their areas now, > so we can fix any problems before the merge. To see the changes, check out > (or diff against) the "wip/android" branch. > > I have appended a list of changed files for the following repositories: > qtsensors I had a very quick look at QtSensors, and there are some inconsistency with units. For example, according to https://developer.android.com/reference/android/hardware/SensorEvent.html#values, the Android API reports magnetic field values in microteslas, whereas the units of QMagnetometerReading are teslas. There doesn't seem to be a conversion in AndroidMagnetometer::onSensorChanged(), so the reported units in QtSensors will be off by a factor of 1000. This should be fixed for several reasons, like portability, documentation being wrong and to have proper functioning sensor gestures, which rely on correct units. I'd advise you to check the other sensors as well, there is no conversion anywhere, that seems too easy to be true to me. Also, please double-check if the axes are correct. Many sensors like the accelerometer have a x, y and z axis. Do these have the same coordinate system as in QtSensors? Do these have the same angle representation (radians vs degrees)? Also, my most beloved sensor, the rotation sensor, uses euler angles (Tait– Bryan, to be exact, IIRC). For euler angles, the order or rotation matters(!). Is that the same in Android? is the unit range the same (for example QRotationReading's y goes from -180 to +180, whereas x goes from -90 to 90)? For the Blackberry backend, I had to convert from the OS sensor service's Z- Y'-X'' system to QtSensor's Z-X'-Y'' system, for example. The documentation of the reading classes in Qt, for example QRotationReading, have quite informative pictures, and in the case of QRotationReading, are even animated, to understand things better. This needs testing. I tested by waving/rotating my phone around (to the amusement of the rest of the office) and comparing the reading values to what the documentation tells they should be. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Tuesday, February 05, 2013 04:17:42 AM BogDan wrote: > > On Tuesday, February 05, 2013 02:58:47 AM BogDan wrote: > >> Hi, > >> > >> > On Tuesday, February 05, 2013 11:33:29 AM Paul Olav Tvete wrote: > >> > [...] > >> > > >> >> mkspecs/android-g++/qmake.conf > >> >> > >> > One suggestion regarding the name of the mkspec: > >> > > >> > It's not unusual to have linux* masks in .pro files (at least not > > > > in > > > >> > WebKit > >> > ;-) > >> > > >> > Would it perhaps make sense to rename the mkspec to linux-android-g++ > > > > to > > > >> > emphasize the fact that at the heart it is still a Linux system > > > > we're > > > >> > building > >> > for? > >> > >> Linux is only the kernel, which can be changed if Google finds a better > >> alternative, and is not required to build an Android application. > >> The rest of the O.S. is Android. IMHO android-g++ is the right name > >> (just like blackberry-*-gcc), Because to build an application we need > >> libs > >> that are Android "specific" (they have their own libc > > > > implementation, etc), > > > >> not the linux kernel. > > > > Yet bionic tries to be glibc compatible'ish. > > > > Changing the underlying kernel would be a major ABI break unless the new > > kernel comes with a compatibility layer (which would seem likely). But the > > day that happens I suggest we introduce a new mkspec ;) > > > > Let's put it this way: linux-g++* is just as fuzzy as android-g++* in what > > it > > means. But we're not in the business of creating mathematical formulas, > > we're > > in the business of making life easier for software developers. If we can > > make it easier for people to port their app to Android, why don't we do > > it? > Why do you think that "./configure -xplatform linux-android-g++ ... " will > make software developer life easier than "./configure -xplatform > android-g++ ... " ? > > There are developer that don't know or don't care what kernel powers the > Android O.S., they know that they have to create an application for > *android* not for linux-android :) IMHO naming it linux-android-g++ will be > confusing for some developers because they will think that linux is > *required* to create android apps, which is not the case ... As you said we > should try to keep the things simple and clear ! Most people won't compile Qt for Android themselves, right? But _many_ more people are going to _use_ it and are likely going to use qmake .pro files. That's where they see the mkspec, that's where it might make a different when porting. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Tuesday, February 05, 2013 01:10:21 PM Eskil Abrahamsen Blomfeldt wrote: > On 02/05/2013 12:49 PM, Friedemann Kleint wrote: > > - Nokia is also mentioned along with names of former employees in the > > json style parser under widgets/styles. Btw, I am generally wondering > > about it, it seems to add a new Json parser. Could it be replaced by > > the Json classes of QtCore? > > We have a task about that. I think it either needs to be replaced by > Qt's json classes or put into 3rdparty. > > > - Compilation of the branch under Windows fails with the attached > > log. Something is probably wrong with #ifdefing/profiles? > > Great, thanks! > > Simon Hausmann wrote: > > Let's put it this way: linux-g++* is just as fuzzy as android-g++* in what > > it means. But we're not in the business of creating mathematical > > formulas, we're in the business of making life easier for software > > developers. If we can make it easier for people to port their app to > > Android, why don't we do it? > I don't have any very strong opinion either way, so whatever the > majority decides is fine by me, but since there's a disagreement: Could > you please elaborate on what makes linux-android-g++ (or > linux-g++-android for symmetry with maemo) simpler for the developer > compared to android-g++? Simply put: Consistency. We do have linux-g++-maemo, linux-g++, linux-arm- gnueabi-g++ They're all flavours of Linux, following the os-compiler/variant pattern. There's no guarantee about what system libraries are in there. In that sense I feel Android is a variant of Linux. In the kernel sense Android is a super-set of the traditional Linux kernel mostly, isn't it? And it's moving closer to mainline step by step. Now after a closer inspection I do have to retract my argument with regards to the use of linux* in WebKit. Just disregard it ;) Consistency is the only argument that I can think of. It's not a strong one, so I won't go on and on about it. But please consider it :) > Technically I don't think Android is considered a Linux-distribution. > Wouldn't this be similar to renaming the OSX mkspec to "macx-g++-darwin"? Given the lack of alternate Darwin based operating systems that we support with Qt, I'm not sure it is that similar. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On 02/05/2013 01:21 PM, BogDan wrote: > last time when I tried Json classes of QtCore were much slower > than the "new" json parser. Because every application that uses native > look and feel must parse a json file every time when it starts, the > parsing speed is a very important factor. Cheers, BogDan. In that case, the json parser in Qt should probably be fixed instead at some point. It doesn't make sense to have two parsers that do the same in Qt. I think we have to replace it with the one in Qt, and if Girish wants, he can submit a faster parser (or someone can put it into 3rdparty and map our APIs on top of it). This is also for QtWidgets which I don't think will be a key ingredient in the offering, since it's not really touch-friendly and not working optimal on single top level windows. -- Eskil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
Hi, [...] > - Nokia is also mentioned along with names of former employees in the json > style > parser under widgets/styles. Btw, I am generally wondering about it, it > seems > to add a new Json parser. Could it be replaced by the Json classes of QtCore? > last time when I tried Json classes of QtCore were much slower than the "new" json parser. Because every application that uses native look and feel must parse a json file every time when it starts, the parsing speed is a very important factor. Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Tue, Feb 5, 2013 at 10:58 AM, BogDan wrote: > Linux is only the kernel, Sure, but that is what "linux" refers to, too. > which can be changed if Google finds a better alternative, > and is not required to build an Android application. > I agree with Simon's longer explanation. I think if that ever happens, this will have to be a day to differentiate between linux and the other kernel if any, like with the prefix proposed. The rest of the O.S. is Android. IMHO android-g++ is the right name > (just like blackberry-*-gcc), Let us stick to consistency first for linux, but I disagree about the establish qnx, too. To me the "confusion" about that you can build on different host than Linux is void because you can do that for maemo, too. The mkspecs is not for specifying the host, but the one you build for (i.e. embedded for instance). Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
> On Tuesday, February 05, 2013 02:58:47 AM BogDan wrote: >> Hi, >> >> > On Tuesday, February 05, 2013 11:33:29 AM Paul Olav Tvete wrote: >> > [...] >> > >> >> mkspecs/android-g++/qmake.conf >> > >> > One suggestion regarding the name of the mkspec: >> > >> > It's not unusual to have linux* masks in .pro files (at least not > in >> > WebKit >> > ;-) >> > >> > Would it perhaps make sense to rename the mkspec to linux-android-g++ > to >> > emphasize the fact that at the heart it is still a Linux system > we're >> > building >> > for? >> > >> > >> >> Linux is only the kernel, which can be changed if Google finds a better >> alternative, and is not required to build an Android application. >> The rest of the O.S. is Android. IMHO android-g++ is the right name >> (just like blackberry-*-gcc), Because to build an application we need libs >> that are Android "specific" (they have their own libc > implementation, etc), >> not the linux kernel. > > Yet bionic tries to be glibc compatible'ish. > > Changing the underlying kernel would be a major ABI break unless the new > kernel comes with a compatibility layer (which would seem likely). But the > day > that happens I suggest we introduce a new mkspec ;) > > Let's put it this way: linux-g++* is just as fuzzy as android-g++* in what > it > means. But we're not in the business of creating mathematical formulas, > we're > in the business of making life easier for software developers. If we can make > it easier for people to port their app to Android, why don't we do it? > Why do you think that "./configure -xplatform linux-android-g++ ... " will make software developer life easier than "./configure -xplatform android-g++ ... " ? There are developer that don't know or don't care what kernel powers the Android O.S., they know that they have to create an application for *android* not for linux-android :) IMHO naming it linux-android-g++ will be confusing for some developers because they will think that linux is *required* to create android apps, which is not the case ... As you said we should try to keep the things simple and clear ! Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On 02/05/2013 12:49 PM, Friedemann Kleint wrote: > - Nokia is also mentioned along with names of former employees in the > json style parser under widgets/styles. Btw, I am generally wondering > about it, it seems to add a new Json parser. Could it be replaced by > the Json classes of QtCore? We have a task about that. I think it either needs to be replaced by Qt's json classes or put into 3rdparty. > > - Compilation of the branch under Windows fails with the attached > log. Something is probably wrong with #ifdefing/profiles? Great, thanks! Simon Hausmann wrote: > Let's put it this way: linux-g++* is just as fuzzy as android-g++* in what it > means. But we're not in the business of creating mathematical formulas, we're > in the business of making life easier for software developers. If we can make > it easier for people to port their app to Android, why don't we do it? I don't have any very strong opinion either way, so whatever the majority decides is fine by me, but since there's a disagreement: Could you please elaborate on what makes linux-android-g++ (or linux-g++-android for symmetry with maemo) simpler for the developer compared to android-g++? Technically I don't think Android is considered a Linux-distribution. Wouldn't this be similar to renaming the OSX mkspec to "macx-g++-darwin"? -- Eskil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
Hi, quickly trying it out, I found: - qplatformdefs.h of Android has a Nokia License of 2009 - surely that was not intended? - Nokia is also mentioned along with names of former employees in the json style parser under widgets/styles. Btw, I am generally wondering about it, it seems to add a new Json parser. Could it be replaced by the Json classes of QtCore? - Compilation of the branch under Windows fails with the attached log. Something is probably wrong with #ifdefing/profiles? Regards, Friedemann -- Friedemann Kleint Digia, Qt c:\qt\qt-5-vs\qt\qtbase\include\qtcore\../../src/corelib/tools/android/cpu-feat res.h(31) : fatal error C1083: Cannot open include file: 'sys/cdefs.h': No such file or directory qglengineshadermanager.cpp Generating Code... jom: C:\qt\qt-5-vs\qt\qtbase\src\opengl\Makefile.Debug [.obj\debug_shared\qglgr dientcache.obj] Error 2 c:\qt\qt-5-vs\qt\qtbase\include\qtcore\../../src/corelib/tools/android/cpu-feat res.h(31) : fatal error C1083: Cannot open include file: 'sys/cdefs.h': No such file or directory Generating Code... jom: C:\qt\qt-5-vs\qt\qtbase\src\opengl\Makefile [debug] Error 2 jom: C:\qt\qt-5-vs\qt\qtbase\src\Makefile [sub-opengl-make_first] Error 2 jom: C:\qt\qt-5-vs\qt\qtbase\Makefile [sub-src-make_first] Error 2 jom: C:\qt\qt-5-vs\qt\Makefile [module-qtbase-make_first] Error 2 C:\bin\jom.exe failed 512: at C:\qt\qt-5-vs\qt\qtrepotools\bin\qt5_tool line 22 . ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Tuesday, February 05, 2013 02:58:47 AM BogDan wrote: > Hi, > > > On Tuesday, February 05, 2013 11:33:29 AM Paul Olav Tvete wrote: > > [...] > > > >> mkspecs/android-g++/qmake.conf > > > > One suggestion regarding the name of the mkspec: > > > > It's not unusual to have linux* masks in .pro files (at least not in > > WebKit > > ;-) > > > > Would it perhaps make sense to rename the mkspec to linux-android-g++ to > > emphasize the fact that at the heart it is still a Linux system we're > > building > > for? > > > > > > Linux is only the kernel, which can be changed if Google finds a better > alternative, and is not required to build an Android application. > The rest of the O.S. is Android. IMHO android-g++ is the right name > (just like blackberry-*-gcc), Because to build an application we need libs > that are Android "specific" (they have their own libc implementation, etc), > not the linux kernel. Yet bionic tries to be glibc compatible'ish. Changing the underlying kernel would be a major ABI break unless the new kernel comes with a compatibility layer (which would seem likely). But the day that happens I suggest we introduce a new mkspec ;) Let's put it this way: linux-g++* is just as fuzzy as android-g++* in what it means. But we're not in the business of creating mathematical formulas, we're in the business of making life easier for software developers. If we can make it easier for people to port their app to Android, why don't we do it? Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
Hi, > > On Tuesday, February 05, 2013 11:33:29 AM Paul Olav Tvete wrote: > [...] >> mkspecs/android-g++/qmake.conf > > One suggestion regarding the name of the mkspec: > > It's not unusual to have linux* masks in .pro files (at least not in WebKit > ;-) > > Would it perhaps make sense to rename the mkspec to linux-android-g++ to > emphasize the fact that at the heart it is still a Linux system we're > building > for? > Linux is only the kernel, which can be changed if Google finds a better alternative, and is not required to build an Android application. The rest of the O.S. is Android. IMHO android-g++ is the right name (just like blackberry-*-gcc), Because to build an application we need libs that are Android "specific" (they have their own libc implementation, etc), not the linux kernel. Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Tue, Feb 5, 2013 at 10:41 AM, Simon Hausmann wrote: > On Tuesday, February 05, 2013 11:33:29 AM Paul Olav Tvete wrote: > [...] > > mkspecs/android-g++/qmake.conf > > One suggestion regarding the name of the mkspec: > > It's not unusual to have linux* masks in .pro files (at least not in > WebKit ;-) > > Would it perhaps make sense to rename the mkspec to linux-android-g++ to > emphasize the fact that at the heart it is still a Linux system we're > building > for? > Yes, as it is similar to the Maemo story. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
On Tuesday, February 05, 2013 11:33:29 AM Paul Olav Tvete wrote: [...] > mkspecs/android-g++/qmake.conf One suggestion regarding the name of the mkspec: It's not unusual to have linux* masks in .pro files (at least not in WebKit ;-) Would it perhaps make sense to rename the mkspec to linux-android-g++ to emphasize the fact that at the heart it is still a Linux system we're building for? Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Reviews needed before android integration in two weeks
One of the major features for Qt 5.1 is Android support. We have been doing the work in a feature branch, and are now getting ready to integrate to the dev branch. To beat the rush of integrations before feature freeze, we aim to start the integration in two weeks time. Most of the changes are android-specific, but there are a few changes touching cross-platform code. To make the integration go smootly, we ask approvers and maintainers to check the android changes in their areas now, so we can fix any problems before the merge. To see the changes, check out (or diff against) the "wip/android" branch. I have appended a list of changed files for the following repositories: qtsensors qtdeclarative qtbase We also have changes in qtmultimedia, but those will probably be merged independently. We urge you to check your area for changes within the coming two weeks. Once the merge commit is created, we aim to integrate it immediately, so there will not be room for a lot of discussion at that point. On behalf of the Qt for Android team, - Paulqtdeclarative M src/quick/items/qquickitem.cpp M src/quick/items/qquicktextedit.cpp M src/quick/items/qquicktextedit_p_p.h M src/quick/items/qquicktextinput.cpp qtsensors A src/plugins/sensors/android/... M src/plugins/sensors/blackberry/main.cpp M src/plugins/sensors/dummy/main.cpp M src/plugins/sensors/generic/main.cpp M src/plugins/sensors/linux/main.cpp M src/plugins/sensors/sensors.pro M src/plugins/sensors/simulator/main.cpp M src/sensors/qsensormanager.cpp M src/sensors/qsensorplugin.h qtbase M config.tests/qpa/linuxfb/linuxfb.cpp M config.tests/unix/arch.test M config.tests/unix/compile.test M config.tests/unix/evdev/evdev.cpp M config.tests/unix/getaddrinfo/getaddrinfotest.cpp A config.tests/unix/ipc_android/ipc.cpp A config.tests/unix/ipc_android/ipc_android.pro M config.tests/unix/makeabs M configure A lib/rules.xml A mkspecs/android-g++/qmake.conf A mkspecs/android-g++/qplatformdefs.h D mkspecs/common/android/qplatformdefs.h D mkspecs/common/linux-android.conf A mkspecs/features/android.prf A mkspecs/features/java.prf M mkspecs/features/moc.prf A mkspecs/features/qpa/android.prf M mkspecs/features/qpa/genericunixfontdatabase.prf M mkspecs/features/qt_functions.prf M mkspecs/features/qt_parts.prf M mkspecs/features/resources.prf M mkspecs/features/static.prf D mkspecs/unsupported/linux-android-armeabi-g++/qmake.conf D mkspecs/unsupported/linux-android-armeabi-g++/qplatformdefs.h D mkspecs/unsupported/linux-android-armeabi-v7a-g++/qmake.conf D mkspecs/unsupported/linux-android-armeabi-v7a-g++/qplatformdefs.h D mkspecs/unsupported/linux-android-x86-g++/qmake.conf D mkspecs/unsupported/linux-android-x86-g++/qplatformdefs.h M qmake/generators/makefile.cpp M qmake/generators/unix/unixmake2.cpp M qmake/generators/win32/mingw_make.cpp M qmake/generators/win32/msvc_nmake.cpp M qtbase.pro A src/android/... M src/corelib/arch/arch.pri A src/corelib/arch/qatomic_android.h M src/corelib/codecs/qiconvcodec.cpp M src/corelib/codecs/qiconvcodec_p.h M src/corelib/codecs/qtextcodec.cpp M src/corelib/codecs/qtextcodec_p.h M src/corelib/global/qglobal.cpp M src/corelib/global/qlogging.cpp M src/corelib/global/qnamespace.h M src/corelib/global/qnamespace.qdoc M src/corelib/global/qsystemdetection.h M src/corelib/io/qabstractfileengine_p.h M src/corelib/io/qfilesystemengine_unix.cpp M src/corelib/io/qfsfileengine_unix.cpp M src/corelib/io/qtemporarydir.cpp M src/corelib/kernel/kernel.pri M src/corelib/kernel/qeventdispatcher_unix.cpp M src/corelib/kernel/qeventdispatcher_unix_p.h M src/corelib/kernel/qsharedmemory.cpp D src/corelib/kernel/qsharedmemory_android.cpp A src/corelib/kernel/qsharedmemory_ashmem.cpp M src/corelib/kernel/qsharedmemory_p.h M src/corelib/kernel/qsystemsemaphore.cpp M src/corelib/kernel/qsystemsemaphore_android.cpp M src/corelib/kernel/qsystemsemaphore_p.h M src/corelib/thread/qbasicatomic.h M src/corelib/thread/qthread_unix.cpp A src/corelib/tools/android/cpu-features.c A src/corelib/tools/android/cpu-features.h M src/corelib/tools/qsimd.cpp M src/corelib/tools/qstring.h M src/corelib/tools/tools.pri M src/gui/image/qimage_neon.cpp M src/gui/kernel/qguiapplication.cpp M src/gui/kernel/qplatforminputcontext.cpp M src/gui/kernel/qplatforminputcontext.h M src/gui/kernel/qplatformmenu.h M src/gui/kernel/qplatformscreen.cpp M src/network/access/qnetworkaccessfilebackend.cpp M src/network/access/qnetworkaccessmanager.cpp M
