Re: [Development] Nominating Andreas Hanssen as Approver
On 02/06/2013 10:42 PM, Olivier Goffart wrote: > On Wednesday 06 February 2013 13:31:40 Thiago Macieira wrote: >> Hello >> >> Andreas is a long-time Qt developer. For those of you who haven't yet had >> the pleasure of meeting him, he's the brains behind the original >> implementation and maintenance of Graphics View. Before that, I remember >> working with him on the networking classes -- in fact, QSslSocket is also >> his and George Staikos's. >> >> His knowledge is invaluable. >> >> You can find him on IRC under the nickname "bibr". > > > +1 > > Welcome back :-) A hearty +1 from me as well. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] issue tracker rights
Hi, On Wed, Feb 6, 2013 at 1:33 PM, Mitch Curtis wrote: >> Bug triaging is a good way to get new contributors involved. So in my >> opinion we should try to encourage everyone to help out with the cleanup of >> our bug- tracker. Maybe we can even learn from KDE for example, where >> regular bug triaging is working nicely. >> (see for example http://techbase.kde.org/Contribute/Bugsquad ) > > I think a lot of people are hesitant to contribute fixes because of all of the > setup required to contribute, also (yeah, it's easy once you are familiar with > it). This has probably been discussed before, but we would get way more fixes > (or at least head starts for fixes, since most patches are not fit for > immediate > submission due to the absence of unit tests, etc.) if we could put a legal > notice somewhere obvious saying that any attachments uploaded imply signing of > the CLA? Speaking for myself, I find it's hardest to figure what to do and at the same time avoid work duplication. Sometimes you can identify a task that is not in the tracker and almost by chance found in Gerrit. Kind Regards, Thiago A. Correa ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] issue tracker rights
On 02/07/2013 02:11 AM, Charley Bay wrote: Mitch sayeth: I think a lot of people are hesitant to contribute fixes because of all of the setup required to contribute, also (yeah, it's easy once you are familiar with it). , +1 It would be nice to make this, "turn-key". For example, on platforms like Windows, it "would-be-nice" to have an "installer" that you could download, which installs a "QtContributor.exe", which is a simple GUI to pull Qt modules or otherwise make "easy" the local-codebase management and compiling/linking/install of a module configuration. I don't want to make "more-work" for anyone, but I think a "contributor-IDE" with contributor-utility-help would be useful (enter/search-for/reproduce bugs, pull module updates so bugs could be reproduced/fixed/verified, etc.) How about an optional Qt Creator plugin shipped with Creator but disabled by default? I know disable by default would be fairly simple because the TODO plugin was done that way for a while. If we want "casual-users" to find/reproduce/look-at bugs, a one-click-setup would be great, IMHO. Yes, once it's "in-place", it's easy. But it's not easy getting it "in-place". Also, many of us must maintain "clean-reference" development environments where we maintain "last-released" development in addition to (wanting-to) closely follow new Qt module development. An easy "module-configurator" tool would be nice for this. I'm thinking of something like a simple GUI on top of Thiago's Qt-module-selector/configurator-scripts. --charley ___ 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] ICU and Windows
On 02/06/2013 11:20 PM, Koehne Kai wrote: > >> -Original Message- >> From: development-bounces+kai.koehne=digia@qt-project.org >> [mailto:development-bounces+kai.koehne=digia@qt-project.org] On >> Behalf Of Thiago Macieira >> Sent: Tuesday, February 05, 2013 6:42 AM >> To: development@qt-project.org >> Subject: Re: [Development] ICU and Windows >> >> [...] >> Also note that the data library is only an inconvenience now because we >> have duplicated data: the Unicode tables and CLDR locale data are in ICU and >> in QtCore. Once we remove our own copy of that data, the total size would >> be reduced. > True, but Qt5Core.dll is about 3,6 MB for me (5.0.1/MSVC 2010 32bit), while > icudt49.dll is 17,5 MB. So the size gain by stripping out things from Qt5Core > can't be really big. > >> I also think that we should configure ICU on Windows to reduce its data size: >> we don't need all of it. > That is what we should do indeed. I learned from > > http://userguide.icu-project.org/icudata > > that one can also ship the ICU data in separate .data files, located in a > "ICU data directory" that can be specified e.g. at compilation time. So how > about creating a bare minimum icudt.dll, and rather ship .data files in a > well-known place ($$[QT_INSTALL_ICU])? This would allow anyone with enough > knowledge to tailor what exactly they want to ship, while reducing the > footprint of "I don't care about localization for hello world" types of > applications. Could documentation also be created on the data files, what each contains and how to include them in the project file? Thanks. > I've to say I'm not at all into Unicode/ICU. Anyone else want to take this up? > > > Regards > > Kai > ___ > 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
[Development] cant folderlistmodel with Qt5
I'm trying to load FolderListModel plugin: import Qt.labs.folderlistmodel 2.0 and got this error: main.qml:2:1: module "Qt.labs.folderlistmodel" is not installed I was using code from that plugin as template to implement my own and start looking around when it didnt work. Plugin is "installed" in qt5/qml as it should, its getting loaded properly by qt5 library system, but looks like import isnt added anyway (error goes from qqmltypeloader). Why? Couldnt find anything usefull on web, so am I doing something wrong here, or is it a little bug? *Łukasz Korbel* Senior Software Developer Milo Solutions (+48) 517539562 http://milosolutions.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 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] Nominating Andreas Hanssen as Approver
+1 Rich. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Andreas Hanssen as Approver
On Wednesday 06 February 2013 13:31:40 Thiago Macieira wrote: > Hello > > Andreas is a long-time Qt developer. For those of you who haven't yet had > the pleasure of meeting him, he's the brains behind the original > implementation and maintenance of Graphics View. Before that, I remember > working with him on the networking classes -- in fact, QSslSocket is also > his and George Staikos's. > > His knowledge is invaluable. > > You can find him on IRC under the nickname "bibr". +1 Welcome back :-) -- 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] Nominating Andreas Hanssen as Approver
What? He isn't an approver yet? Seconded! On 02/06/2013 10:33 PM, Robin Burchell wrote: > Seconded happily. Unlike you, I haven't had the chance to work with > him, but I've seen his work around the place :) > > On Wed, Feb 6, 2013 at 10:31 PM, Thiago Macieira > wrote: >> Hello >> >> Andreas is a long-time Qt developer. For those of you who haven't yet had the >> pleasure of meeting him, he's the brains behind the original implementation >> and maintenance of Graphics View. Before that, I remember working with him on >> the networking classes -- in fact, QSslSocket is also his and George >> Staikos's. >> >> His knowledge is invaluable. >> >> You can find him on IRC under the nickname "bibr". >> >> His dashboards: >> https://codereview.qt-project.org/#dashboard,1000351 >> https://codereview.qt-project.org/#dashboard,1001692 >> >> More importantly, the list of reviews: >> https://codereview.qt-project.org/#q,reviewer: >> %2522Andreas+Aardal+Hanssen%2522,n,z >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >>Software Architect - Intel Open Source Technology Center >> >> ___ >> 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 > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Andreas Hanssen as Approver
Seconded happily. Unlike you, I haven't had the chance to work with him, but I've seen his work around the place :) On Wed, Feb 6, 2013 at 10:31 PM, Thiago Macieira wrote: > Hello > > Andreas is a long-time Qt developer. For those of you who haven't yet had the > pleasure of meeting him, he's the brains behind the original implementation > and maintenance of Graphics View. Before that, I remember working with him on > the networking classes -- in fact, QSslSocket is also his and George > Staikos's. > > His knowledge is invaluable. > > You can find him on IRC under the nickname "bibr". > > His dashboards: > https://codereview.qt-project.org/#dashboard,1000351 > https://codereview.qt-project.org/#dashboard,1001692 > > More importantly, the list of reviews: > https://codereview.qt-project.org/#q,reviewer: > %2522Andreas+Aardal+Hanssen%2522,n,z > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > 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
[Development] Nominating Andreas Hanssen as Approver
Hello Andreas is a long-time Qt developer. For those of you who haven't yet had the pleasure of meeting him, he's the brains behind the original implementation and maintenance of Graphics View. Before that, I remember working with him on the networking classes -- in fact, QSslSocket is also his and George Staikos's. His knowledge is invaluable. You can find him on IRC under the nickname "bibr". His dashboards: https://codereview.qt-project.org/#dashboard,1000351 https://codereview.qt-project.org/#dashboard,1001692 More importantly, the list of reviews: https://codereview.qt-project.org/#q,reviewer: %2522Andreas+Aardal+Hanssen%2522,n,z -- 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 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] abandoning stale changes on gerrit
On 01/31/2013 07:49 AM, Oswald Buddenhagen wrote: > On Thu, Jan 31, 2013 at 01:59:17PM +0100, Paul Olav Tvete wrote: >> On Thursday 31 January 2013 13:08:11 Oswald Buddenhagen wrote: >>> as i stated before, i'm driving forward a process to decide the >>> execution details of a previously made decision. >> Since this decision process has been unnoticed by the people I have asked: >> Would you mind giving a reference to where this was discussed? >> > the thread i could find is > http://comments.gmane.org/gmane.comp.lib.qt.opengov/257 > there was clearly support and not a single dissent. if you raise > objections now, it must be considered re-visiting a made decision. you > should bring real arguments to the table then, ones which i did not > rebut already. Policies like this should be recorded in the qt-project.org wiki. This will come up again, and it's unreasonable to expect someone to find, read, and understand the conclusion of a mailing list discussion when a few sentences in a central location will suffice. The wiki could probably use some house keeping. Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
On 01/31/2013 03:19 AM, Chris Adams wrote: > Slightly off-topic, but in any event, I think we can all agree that > there's a huge difference between a good QML API and a good C++ API. > I haven't looked at it, but if Alan thinks that QScreen, as is, > shouldn't be exposed to QML as a property of QQuickItem, then I think > that we need some serious discussion and review before I'd give a +1 > to it. A review should reflect your opinion of a patch, rather than your opinion or expectations of other (potential) reviews. If a patch looks good to you, +1 it. If you don't' like it, -1 it. +2 and -2 are stronger versions, for areas where you feel sufficiently knowledgeable and authoritative. Holding back until someone else reviews doesn't contribute to the project. Other reviewers might be waiting for you, for the same reason. This doesn't mean that you can't change a score after being convinced by another review. Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ChangeLogs
On Thursday 31 January 2013 07:50:32 Koehne Kai wrote: > > -Original Message- > > From: development-bounces+kai.koehne=digia@qt-project.org > > [mailto:development-bounces+kai.koehne=digia@qt-project.org] On > > Behalf Of Matt Williams > > Sent: Tuesday, January 29, 2013 11:14 AM > > To: development > > Subject: Re: [Development] ChangeLogs > > > > On 29 January 2013 00:31, Alan Alpert <4163654...@gmail.com> wrote: > > > On Mon, Jan 28, 2013 at 4:21 AM, Jason McDonald > > > > wrote: > > >> 4. Let's try to make the job of our maintainers that little bit > > >> easier by writing good commit summaries and diligently reviewing the > > >> commit summaries of our peers. > > > > > > +1, but I think the tool is a more realistic way of making the task > > > easier for the maintainers. > > > > Within KDE we use a tool called Enzyme (http://enzyme-project.org/) which > > allows you to go through all the commits, marking certain ones as > > interesting in a collaborative way. It might not have _all_ the feature > > needed but it would probably help along the way. It's open-source so we > > could always tweak it as needed. > > I'm all for a tool making things easier for the one writing the actual > ChangeLog file. But I think it's somewhat orthogonal to the question > whether the original author of a fix should write a ChangeLog line > somewhere, too . > > So, did we come to any conclusion regarding adding a "ChangeLog: " entry to > commits? IMO it's worth a try. I'd say yes, Put a "Changelog:" entry somewhere with some text that will be processed manually by the release manager to fill the changelog. (The release manager can grep for it, and that will ease his task a lot to have already ready made sentence) [ The ones who are concerned about a bit of reddundancy in the commit message should as well leave the commit empty since it is already redundent with the diff itself :-) ] -- 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
[...] >> >> 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] SSL Certificate verification overriding !!
Thank you Richard. Sorry for sending to the wrong mailing list :( On 6 February 2013 18:47, Richard Moore wrote: > See http://www.youtube.com/watch?v=btLCVoEuEr8 for a talk on this topic. > The examples are at > https://gitorious.org/qt-examples/qt-examples/trees/master/ssl-examples > > For future reference, questions like this should be sent to the > inter...@qt-project.org list not the development list. > > Cheers > > Rich. > > On 6 February 2013 06:34, Arunprasad Rajkumar wrote: > >> SSL peer certificate verification > > > > -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] issue tracker rights
Mitch sayeth: > I think a lot of people are hesitant to contribute fixes because of all of > the > setup required to contribute, also (yeah, it's easy once you are familiar > with > it). , +1 It would be nice to make this, "turn-key". For example, on platforms like Windows, it "would-be-nice" to have an "installer" that you could download, which installs a "QtContributor.exe", which is a simple GUI to pull Qt modules or otherwise make "easy" the local-codebase management and compiling/linking/install of a module configuration. I don't want to make "more-work" for anyone, but I think a "contributor-IDE" with contributor-utility-help would be useful (enter/search-for/reproduce bugs, pull module updates so bugs could be reproduced/fixed/verified, etc.) If we want "casual-users" to find/reproduce/look-at bugs, a one-click-setup would be great, IMHO. Yes, once it's "in-place", it's easy. But it's not easy getting it "in-place". Also, many of us must maintain "clean-reference" development environments where we maintain "last-released" development in addition to (wanting-to) closely follow new Qt module development. An easy "module-configurator" tool would be nice for this. I'm thinking of something like a simple GUI on top of Thiago's Qt-module-selector/configurator-scripts. --charley ___ 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] issue tracker rights
On Wednesday, February 06, 2013 12:52:29 PM Frederik Gladhorn wrote: > Hello all, > > yesterday we did a bug triaging and fixing day here in the Digia Oslo > office. While everyone always looks at the bugs a little bit, it is > sometimes good to actually go through them and figure out if they are valid > and their priority so we know what to work on. > > Traditionally we have been rather protective of our issues, allowing people > to file reports in jira, but not let anyone re-open or close them. > I think it would be a good time to re-think our policies for bugs. > > I would like to propose that everyone (with an account) gets the ability to > create/close/re-open bugs. I don't think anyone will steal our bugs and run > away with them. In addition one gets a notification for subscribed bugs, so > it's easy to re-open a bug. > > I am not sure what the best policy is about assigning priorities to bugs, > should everyone be able to prioritize? Of course everyone has their bug as > the most important thing in the world. We probably need to creat a good > guideline for this on the wiki. It would be nice to have a feature where this stuff could be requested rather than done immediately. The reason being that if a bug is mistakenly closed, it won't show up in the filters that we use for evaluating our bugs for each release. If a bug is mistakenly reopened, it's not so bad, but it still adds housekeeping overhead for whoever has to re-verify it, etc. Of course, someone will still have to respond to the requests; perhaps the reporter is notified upon requests to close and the reporter, assignee and user who closed the task when something is requested to reopened. There would still need to be someone who was notified regardless to account for the cases where the reporter is no longer active in the community. > Another point is assignment. We have the default asignees, but these are > often maintainers and in some areas they won't be able to fix all bugs. > Probably everyone should be able to assign a bug to themselves at least > when it is unassigned. > I also think it's good to have unassigned bugs when no one will be working > on them in the forseable future - those are up for grabs for everyone. This I definitely agree with. There's very little disadvantage to giving everyone assignment rights (or at least the "Assign To Me" button); the only one I can think of is when someone is assigned a bug mistakenly. If someone "steals" a task (rarely happens anyway AFAIK), the previous assignee will be notified anyway. > Bug triaging is a good way to get new contributors involved. So in my > opinion we should try to encourage everyone to help out with the cleanup of > our bug- tracker. Maybe we can even learn from KDE for example, where > regular bug triaging is working nicely. > (see for example http://techbase.kde.org/Contribute/Bugsquad ) I think a lot of people are hesitant to contribute fixes because of all of the setup required to contribute, also (yeah, it's easy once you are familiar with it). This has probably been discussed before, but we would get way more fixes (or at least head starts for fixes, since most patches are not fit for immediate submission due to the absence of unit tests, etc.) if we could put a legal notice somewhere obvious saying that any attachments uploaded imply signing of the CLA? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Gardening (merging of branches)
Hello again, if you follow gerrit and the git repos closely you might have noticed that we have merged the branches in a more regular fashion lately. With our current setup we need to continously go this path: release -> stable -> dev On a side note: Please only submit your patch for one branch. It will end up in the appropriate branches over time. We'd rather not have patches in multiple times as that just creates confusion. Sergio and I with the help of Jedrzej and others have been pushing the merges lately. I initially thought this can be automated mostly, but about half the time (at least for qtbase) there is a conflict. At that point manual intervention is required. The merging can be tedious (I had one case where I depended on the person responsible for half the conflicts to help me figure out how things should be), but is generally not rocket science. If possible sitting with two people to do it and at the same time review it was the best approach for some conflicts, I recommend this to anyone who has the luxury of sitting in the same office as another contributor. Reviewing merges is a bit funny, they show up empty in gerrit: https://codereview.qt-project.org/#change,46862 That means you need to check them out. Then you can do a combination of git show and using gitk or other tools to verify that the merge was done the right way. In order to push merges you need special gerrit karma. Approvers can review and approve merges as usual. After talking to several people, for example today on IRC Sean Harmer, I think it's a good idea to let more people participate in the joy of creating merges. Initially it takes some time, but once you get the hang of git and merges, it becomes quite doable without too much pain (apart from big conflicts every once in a while). I would suggest to look at for example webkit (a suggestion that Simon originally made) and how they do "gardening". For a limited time (could be two weeks?) two approvers get the honor to look that integration works and that there will be regular merges. I think about weekly is not so bad, unless there is a special request to do it faster. This is a nice way to learn about a few more things in how the releases come together and you may discover interesting new bits in Qt, code that you've never seen before. At least that part is fun ;) Since it requred merge rights, I would suggest we start with some of the maintainers, if we want to try this approach. Btw: we seem to face a bug in gerrit: it seems like patches that are contained in a merge and are at the same time on gerrit in an unreviewed stage get the CI to hang. So it's appreciated if patches that are around twice with the same change id in different branches get abandonned after one of them has been merged. -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ICU and Windows
> -Original Message- > From: development-bounces+kai.koehne=digia@qt-project.org > [mailto:development-bounces+kai.koehne=digia@qt-project.org] On > Behalf Of Thiago Macieira > Sent: Tuesday, February 05, 2013 6:42 AM > To: development@qt-project.org > Subject: Re: [Development] ICU and Windows > > [...] > Also note that the data library is only an inconvenience now because we > have duplicated data: the Unicode tables and CLDR locale data are in ICU and > in QtCore. Once we remove our own copy of that data, the total size would > be reduced. True, but Qt5Core.dll is about 3,6 MB for me (5.0.1/MSVC 2010 32bit), while icudt49.dll is 17,5 MB. So the size gain by stripping out things from Qt5Core can't be really big. > I also think that we should configure ICU on Windows to reduce its data size: > we don't need all of it. That is what we should do indeed. I learned from http://userguide.icu-project.org/icudata that one can also ship the ICU data in separate .data files, located in a "ICU data directory" that can be specified e.g. at compilation time. So how about creating a bare minimum icudt.dll, and rather ship .data files in a well-known place ($$[QT_INSTALL_ICU])? This would allow anyone with enough knowledge to tailor what exactly they want to ship, while reducing the footprint of "I don't care about localization for hello world" types of applications. I've to say I'm not at all into Unicode/ICU. Anyone else want to take this up? Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] SSL Certificate verification overriding !!
See http://www.youtube.com/watch?v=btLCVoEuEr8 for a talk on this topic. The examples are at https://gitorious.org/qt-examples/qt-examples/trees/master/ssl-examples For future reference, questions like this should be sent to the inter...@qt-project.org list not the development list. Cheers Rich. On 6 February 2013 06:34, Arunprasad Rajkumar wrote: > SSL peer certificate verification ___ 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
[Development] issue tracker rights
Hello all, yesterday we did a bug triaging and fixing day here in the Digia Oslo office. While everyone always looks at the bugs a little bit, it is sometimes good to actually go through them and figure out if they are valid and their priority so we know what to work on. Traditionally we have been rather protective of our issues, allowing people to file reports in jira, but not let anyone re-open or close them. I think it would be a good time to re-think our policies for bugs. I would like to propose that everyone (with an account) gets the ability to create/close/re-open bugs. I don't think anyone will steal our bugs and run away with them. In addition one gets a notification for subscribed bugs, so it's easy to re-open a bug. I am not sure what the best policy is about assigning priorities to bugs, should everyone be able to prioritize? Of course everyone has their bug as the most important thing in the world. We probably need to creat a good guideline for this on the wiki. Another point is assignment. We have the default asignees, but these are often maintainers and in some areas they won't be able to fix all bugs. Probably everyone should be able to assign a bug to themselves at least when it is unassigned. I also think it's good to have unassigned bugs when no one will be working on them in the forseable future - those are up for grabs for everyone. Bug triaging is a good way to get new contributors involved. So in my opinion we should try to encourage everyone to help out with the cleanup of our bug- tracker. Maybe we can even learn from KDE for example, where regular bug triaging is working nicely. (see for example http://techbase.kde.org/Contribute/Bugsquad ) -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Hebrew
On 2/5/13 4:06 PM, "Thiago Macieira" wrote: >On terça-feira, 5 de fevereiro de 2013 11.19.39, Diego Iastrubni wrote: >> Note that Qt3 had a very good support for Arabic/Hebrew/Farse (RTL in >> general). I still remember sitting with Lars back in 2003 in (crap >>forgot >> where in Germany that aKademy was...). > >It was in a nice place called Nové Hrady, Czech Republic. And the >conference >was called Kastle. The name aKademy didn't come about until the next >year, >when the conference was in Ludwigsburg, Germany. > >> Things were very good in Qt4 days, >> and now with the move to QtQuick things got bad again. We need to code, >> test and fix Qt5. > >That's a very good point. RTL support needs to be verified in Qt Quick. Actually quite a bit of work has been done there, and it's better in Qt Quick 2 then in Qt Quick 1. But IMO most of the work will actually need to happen on the level of the Qt Quick Components. 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 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
