Re: [Development] Linker Error While linking application(form of DLL) with Qt libs
On segunda-feira, 18 de março de 2013 11.25.43, Amogh Kudari wrote: Hi All, Any idea on how to proceed to remove the linker errors mentioned below. Please provide any inputs/suggestions. I suggest you try asking the mailing list dedicated to discussing development with Qt, as opposed to the mailing list that discusses development of Qt. You have a Qt 4 problem. -- 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] White space / coding style patches welcome?
On 15 Mar 2013, at 2:03 PM, Alberto Mardegan wrote:
Not much relevant here, but just in the unlikely event that everyone
will confess to like this style more, here's what I use in my own projects:
MyClass::MyClass(...):
GvbWidget(parent),
m_background()
{
I do that too. But I usually put a space before the colon.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Starting preparations for Qt 5.1
Hi, Making of Qt 5.1 minor release will soon start: - Plan is to move 'dev' into 'stable' branch on March 19th. - After March 19th any changes that are required to get in for 5.1 need to be pushed into 'stable' branch. So if your needed changes don't make it today, please wait after the merge is done and re-target it. - I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed. - If we decide to do 5.0.3, it could be done from the 'release' branch. Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Starting preparations for Qt 5.1
Making of Qt 5.1 minor release will soon start: - Plan is to move 'dev' into 'stable' branch on March 19th. - After March 19th any changes that are required to get in for 5.1 need to be pushed into 'stable' branch. So if your needed changes don't make it today, please wait after the merge is done and re-target it. - I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed. - If we decide to do 5.0.3, it could be done from the 'release' branch. Considering that people have been developing on stable on the basis that it is in fact 5.0.x, I think we should at least make sure that those changes end up somewhere in case we do a 5.0.3 release for whatever reason. Rather than lose those changes because we merged, could a read only branch be created from the current stable and then merge that into release should a 5.0.3 release happen? So no more work would be done for 5.0.x unless it is decided to make a 5.0.3 release. Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Starting preparations for Qt 5.1
On Monday 18 March 2013 10:27:45 Shaw Andy wrote: Making of Qt 5.1 minor release will soon start: - Plan is to move 'dev' into 'stable' branch on March 19th. - After March 19th any changes that are required to get in for 5.1 need to be pushed into 'stable' branch. So if your needed changes don't make it today, please wait after the merge is done and re-target it. - I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed. - If we decide to do 5.0.3, it could be done from the 'release' branch. Considering that people have been developing on stable on the basis that it is in fact 5.0.x, I think we should at least make sure that those changes end up somewhere in case we do a 5.0.3 release for whatever reason. Rather than lose those changes because we merged, could a read only branch be created from the current stable and then merge that into release should a 5.0.3 release happen? So no more work would be done for 5.0.x unless it is decided to make a 5.0.3 release. I agree. 5.0.3 may never happen but this is good practise and a sensible precaution to take in case we do decide to release one. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Linker Error While linking application(form of DLL) with Qt libs
Hi Thiago, Thanks for your response. I am unaware of the group that is dedicated to discussing development with Qt. Can you provide some info about it (email id and registration). Regards, Amogh. On Mon, Mar 18, 2013 at 11:54 AM, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 18 de março de 2013 11.25.43, Amogh Kudari wrote: Hi All, Any idea on how to proceed to remove the linker errors mentioned below. Please provide any inputs/suggestions. I suggest you try asking the mailing list dedicated to discussing development with Qt, as opposed to the mailing list that discusses development of Qt. You have a Qt 4 problem. -- 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
Re: [Development] Starting preparations for Qt 5.1
On 18.3.2013 12.42, Sean Harmer sean.har...@kdab.com wrote: On Monday 18 March 2013 10:27:45 Shaw Andy wrote: Making of Qt 5.1 minor release will soon start: - Plan is to move 'dev' into 'stable' branch on March 19th. - After March 19th any changes that are required to get in for 5.1 need to be pushed into 'stable' branch. So if your needed changes don't make it today, please wait after the merge is done and re-target it. - I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed. - If we decide to do 5.0.3, it could be done from the 'release' branch. Considering that people have been developing on stable on the basis that it is in fact 5.0.x, I think we should at least make sure that those changes end up somewhere in case we do a 5.0.3 release for whatever reason. Rather than lose those changes because we merged, could a read only branch be created from the current stable and then merge that into release should a 5.0.3 release happen? So no more work would be done for 5.0.x unless it is decided to make a 5.0.3 release. I agree. 5.0.3 may never happen but this is good practise and a sensible precaution to take in case we do decide to release one. It is not very likely that someone decides to stay with 5.0.x, so whatever we do should be such that encourages users to get to 5.1.x, thus we do not need 5.0.x to overlap with 5.1.x as we do with 4.8.x. As you know 5.0.2 is in the works to be out soon and will introduce a great number of fixes over 5.0.1. I hope they are enough to carry us to 5.1.0. I see three reasons for making 5.0.3: - A security issue mandating immediate fix release = that can and should be done on top of 5.0.2 with a minimal amount of fixes directly in the release branch - A 'brown paper bag' issue in 5.0.2 mandating fix and making or 5.0.3 to have something usable = that can and should be done in the release branch with very small amount of changes to 5.0.2 - Severe problems in getting 5.1 out increasing the need of getting 5.0.3 = In this situation everyone doing releases is working with 5.1, so even if there is a need, we can not make 5.0.3 without causing even more problems to 5.1 (please not that this is a theoretical situation, I do not expect any problems with 5.1) Thus I think that it is enough to tag the stable branch before we merge from dev. In case we ever need to get the situation before, it can be done easily. Yours, Tuukka ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Starting preparations for Qt 5.1
On Monday 18 March 2013 11:00:57 Turunen Tuukka wrote: On 18.3.2013 12.42, Sean Harmer sean.har...@kdab.com wrote: On Monday 18 March 2013 10:27:45 Shaw Andy wrote: Making of Qt 5.1 minor release will soon start: - Plan is to move 'dev' into 'stable' branch on March 19th. - After March 19th any changes that are required to get in for 5.1 need to be pushed into 'stable' branch. So if your needed changes don't make it today, please wait after the merge is done and re-target it. - I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed. - If we decide to do 5.0.3, it could be done from the 'release' branch. Considering that people have been developing on stable on the basis that it is in fact 5.0.x, I think we should at least make sure that those changes end up somewhere in case we do a 5.0.3 release for whatever reason. Rather than lose those changes because we merged, could a read only branch be created from the current stable and then merge that into release should a 5.0.3 release happen? So no more work would be done for 5.0.x unless it is decided to make a 5.0.3 release. I agree. 5.0.3 may never happen but this is good practise and a sensible precaution to take in case we do decide to release one. It is not very likely that someone decides to stay with 5.0.x, so whatever we do should be such that encourages users to get to 5.1.x, thus we do not need 5.0.x to overlap with 5.1.x as we do with 4.8.x. As you know 5.0.2 is in the works to be out soon and will introduce a great number of fixes over 5.0.1. I hope they are enough to carry us to 5.1.0. I see three reasons for making 5.0.3: - A security issue mandating immediate fix release = that can and should be done on top of 5.0.2 with a minimal amount of fixes directly in the release branch - A 'brown paper bag' issue in 5.0.2 mandating fix and making or 5.0.3 to have something usable = that can and should be done in the release branch with very small amount of changes to 5.0.2 - Severe problems in getting 5.1 out increasing the need of getting 5.0.3 = In this situation everyone doing releases is working with 5.1, so even if there is a need, we can not make 5.0.3 without causing even more problems to 5.1 (please not that this is a theoretical situation, I do not expect any problems with 5.1) Thus I think that it is enough to tag the stable branch before we merge from dev. In case we ever need to get the situation before, it can be done easily. Since you list several reasons why we may well need a Qt 5.0.3, then why not do it properly and just make a branch as Andy suggests? What is the downside? Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Starting preparations for Qt 5.1
On 3/18/13 12:04 PM, Sean Harmer sean.har...@kdab.com wrote: On Monday 18 March 2013 11:00:57 Turunen Tuukka wrote: On 18.3.2013 12.42, Sean Harmer sean.har...@kdab.com wrote: On Monday 18 March 2013 10:27:45 Shaw Andy wrote: Making of Qt 5.1 minor release will soon start: - Plan is to move 'dev' into 'stable' branch on March 19th. - After March 19th any changes that are required to get in for 5.1 need to be pushed into 'stable' branch. So if your needed changes don't make it today, please wait after the merge is done and re-target it. - I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed. - If we decide to do 5.0.3, it could be done from the 'release' branch. Considering that people have been developing on stable on the basis that it is in fact 5.0.x, I think we should at least make sure that those changes end up somewhere in case we do a 5.0.3 release for whatever reason. Rather than lose those changes because we merged, could a read only branch be created from the current stable and then merge that into release should a 5.0.3 release happen? So no more work would be done for 5.0.x unless it is decided to make a 5.0.3 release. I agree. 5.0.3 may never happen but this is good practise and a sensible precaution to take in case we do decide to release one. It is not very likely that someone decides to stay with 5.0.x, so whatever we do should be such that encourages users to get to 5.1.x, thus we do not need 5.0.x to overlap with 5.1.x as we do with 4.8.x. As you know 5.0.2 is in the works to be out soon and will introduce a great number of fixes over 5.0.1. I hope they are enough to carry us to 5.1.0. I see three reasons for making 5.0.3: - A security issue mandating immediate fix release = that can and should be done on top of 5.0.2 with a minimal amount of fixes directly in the release branch - A 'brown paper bag' issue in 5.0.2 mandating fix and making or 5.0.3 to have something usable = that can and should be done in the release branch with very small amount of changes to 5.0.2 - Severe problems in getting 5.1 out increasing the need of getting 5.0.3 = In this situation everyone doing releases is working with 5.1, so even if there is a need, we can not make 5.0.3 without causing even more problems to 5.1 (please not that this is a theoretical situation, I do not expect any problems with 5.1) Thus I think that it is enough to tag the stable branch before we merge from dev. In case we ever need to get the situation before, it can be done easily. Since you list several reasons why we may well need a Qt 5.0.3, then why not do it properly and just make a branch as Andy suggests? What is the downside? If required, we can always create that branch later on (ie. branch from the latest sha1 in stable before we merged dev back to stable). Is there a real reason why we should do it now? I don't really see one. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Signals/slots for class templates (Was: Evolving Qt's multithreading API)
On 3/17/13 5:21 PM, Olivier Goffart oliv...@woboq.com wrote: On Sunday 17 March 2013 08:13:21 Thiago Macieira wrote: On domingo, 17 de março de 2013 11.13.01, Olivier Goffart wrote: On Sunday 10 March 2013 10:09:24 Thiago Macieira wrote: On domingo, 10 de março de 2013 23.54.42, Sze Howe Koh wrote: What's holding us back? What does installing the moc file mean? You install the output from moc. Yes. That is a build system issue which is not difficult to solve. And it's only if the said QObject is in a header file which also needs to be installed, and that you do not rely on extern template. Are you recommending that people use this feature only for non-public classes? I'm saying that it can be used first with non-public classes before we change the build system to install the needed generated files. We're about to start the 5.1 process (ie. branch into stable) etc, and the feature is not blocking anything critical for the release. So I'd say give it some time and let's get it in properly for 5.2. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QA] Suggestion -- Setting Up the Priority in JIRA
On 3/14/13 1:00 PM, Jason McDonald macadd...@gmail.com wrote: On Wed, Mar 13, 2013 at 11:48 PM, Anttila Janne janne.antt...@digia.com wrote: Jason McDonald wrote: On Wed, Mar 13, 2013 at 2:42 AM, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 12 de março de 2013 13.28.37, Motyka Rafal wrote: Hello, I want to suggest another change for JIRA: - A Reporter should be able to set the Priority starting from the Create Issue window. - Guidelines for setting Priority should be provided (already working today). Please feel free to comment on this. If there are no serious objections, this change will be introduced soon. The impact of the change will be evaluated. I disagree. The priority should be set by the triager, the person who can make a dispassionate, objective assessment of the bug's priority. The bug reporter is way too involved to make that assessment. When we first introduced Jira, we allowed the priority field to be set by the reporter, and this resulted in me spending rather a lot of time turning P0's and P1's into P3's and P4's. Before long my boss decided to hide the priority field from the Create Issue form. I don't know whether the climate has changed enough since then for it to be reasonable to expect a different result if we were to put the priority field back in the form. Would it be possible to bring priority field back for certain JIRA roles, if not for everyone? Sure, approvers and maintainers were not the source of the problem. The grossly exaggerated priorities mostly came from Qt users (as opposed to those developing Qt) and from a subset of Nokia's QA contractors. We could certainly benefit from better initial information on the bug. The way to solve this could be to use some sort of questionnaire during the creation of the bug (does it cause crashes, do you have a workaround, etc.) and compute an initial priority depending on the answers. Still I think we need to make it easy for people to get 'bug evaluation' privileges in Jira without requiring them to be Approvers. So a group for people with somewhat extended Jira editing rights would be a good thing IMO. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Starting preparations for Qt 5.1
On 18 March 2013 11:24, Ahumada Sergio sergio.ahum...@digia.com wrote: Making of Qt 5.1 minor release will soon start: - Plan is to move 'dev' into 'stable' branch on March 19th. - After March 19th any changes that are required to get in for 5.1 need to be pushed into 'stable' branch. So if your needed changes don't make it today, please wait after the merge is done and re-target it. I don't like this very much. We've been running late with the merge, but giving people a 1 day notice (without prior warnings) seems unfair. And, I think stable should never get broken w.r.t. forward binary compatibility, unless at very specific points -- i.e. when we merge -dev into it. The branch guidelines indeed specify that we should freeze and stabilize -dev, not -stable, and release 5.1 alpha out of -dev, not -stable, so that eventual API/ABI fixes to 5.1 material go into -dev. We should merge only when in -beta quality. -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Starting preparations for Qt 5.1
On 18 March 2013 14:22, Ahumada Sergio sergio.ahum...@digia.com wrote: About the tag, one could argue that making the tag (and alpha release) before or after the merge might be the same. This is not only about making the 5.1.0-alpha1 tag. This is about not breaking forward binary compatibility in stable unless extraordinary circumstances. The branch guidelines imply that we should not merge unless we are (almost) in beta quality, see http://i.imgur.com/N1jVW.png (from http://qt-project.org/wiki/Branch-Guidelines , 2nd picture). We can declare dev frozen and not accept any new significant/destabilizing feature, but I disagree on the point that we should retarget small new features (pending, not yet +2d) to stable, as well as getting the first round of API feedback (which could mean API/ABI breaks) in stable. (That of course could still happen after a beta released from -stable, but it would probably require much stronger arguments in order to go through.) Just my 2c, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Starting preparations for Qt 5.1
On Monday, March 18, 2013 13:22:32 Ahumada Sergio wrote: - Plan is to move 'dev' into 'stable' branch on March 19th. - After March 19th any changes that are required to get in for 5.1 http://lists.qt-project.org/pipermail/development/2013-February/009838.html Is there any concern about how this is affected by integrations of qt5.git? https://codereview.qt-project.org/#q,status:open+project:qt/qt5,n,z For example, qtsensors is not yet part of it. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Signals/slots for class templates (Was: Evolving Qt's multithreading API)
On Monday 18 March 2013 11:35:27 Knoll Lars wrote: We're about to start the 5.1 process About to... but not yet started. So no restrictions applies yet. (ie. branch into stable) etc, and the feature is not blocking anything critical for the release. So I'd say give it some time and let's get it in properly for 5.2. I tought the whole point of the system with dev / stable / release was that dev was never frozen. Point is: even if it is not going to be in 5.1, it is not a reason to refuse talking about it. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Signals/slots for class templates (Was: Evolving Qt's multithreading API)
On segunda-feira, 18 de março de 2013 15.16.34, Olivier Goffart wrote: On Monday 18 March 2013 11:35:27 Knoll Lars wrote: We're about to start the 5.1 process About to... but not yet started. So no restrictions applies yet. Correct. Since you are done, you could integrate. But here's the maintainer kindly asking you not to, so we have more time to understand the consequences. (ie. branch into stable) etc, and the feature is not blocking anything critical for the release. So I'd say give it some time and let's get it in properly for 5.2. I tought the whole point of the system with dev / stable / release was that dev was never frozen. It isn't frozen. Point is: even if it is not going to be in 5.1, it is not a reason to refuse talking about it. We are talking about it. Can you tell us more about the long-term plan? What do you plan on documenting? What can people depend on? Will you make moc's output files respect source- and binary-compatibility? -- 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] [Releasing] Starting preparations for Qt 5.1
Hi, On Monday 18 March 2013 16:18:07 Knoll Lars wrote: On Mon, Mar 18, 2013 at 10:24:23AM +, Ahumada Sergio wrote: Hi, Making of Qt 5.1 minor release will soon start: - Plan is to move 'dev' into 'stable' branch on March 19th. i'd like to raise a formal objection. CI was virtually unusable for two weeks now. due to that there is a completely unreasonable backlog of changes meant for 5.1 now. it makes no sense to re-target (or even deny them) due to infrastructure problems. We have said that we'll move to time based releases. Should we stop this because we aren't yet good enough in controlling our systems? I don't think so. It might feel unfair to some people, but we've had these discussions about some features missing the deadline every single minor release. Now if there are one or two features that are vital to make Qt 5.1 possible, we can discuss exceptions for those. QtSensors needs to be added to qt5.git, but couldn't yet, due to CI failures. See https://codereview.qt-project.org/#change,48905. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo 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] [Releasing] Starting preparations for Qt 5.1
On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire thomas.mcgu...@kdab.comwrote: QtSensors needs to be added to qt5.git, but couldn't yet, due to CI failures. See https://codereview.qt-project.org/#change,48905. + QtSerialPort: https://codereview.qt-project.org/#change,49157 Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Starting preparations for Qt 5.1
On 3/18/13 4:58 PM, Laszlo Papp lp...@kde.org wrote: On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire thomas.mcgu...@kdab.com wrote: QtSensors needs to be added to qt5.git, but couldn't yet, due to CI failures. See https://codereview.qt-project.org/#change,48905. + QtSerialPort: https://codereview.qt-project.org/#change,49157 + Mac and X11 extras. Yes, these are known. In addition, we need to get qt5.git updated to recent sha1's of all qt modules. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Starting preparations for Qt 5.1
Don't you mean Mac and Windows? I thought X11 was added a while ago. Sent from my iPhone On Mar 18, 2013, at 12:05 PM, Knoll Lars lars.kn...@digia.com wrote: On 3/18/13 4:58 PM, Laszlo Papp lp...@kde.org wrote: On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire thomas.mcgu...@kdab.com wrote: QtSensors needs to be added to qt5.git, but couldn't yet, due to CI failures. See https://codereview.qt-project.org/#change,48905. + QtSerialPort: https://codereview.qt-project.org/#change,49157 + Mac and X11 extras. Yes, these are known. In addition, we need to get qt5.git updated to recent sha1's of all qt modules. Cheers, Lars ___ 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] [Releasing] Starting preparations for Qt 5.1
On Mon, Mar 18, 2013 at 12:31 PM, Knoll Lars lars.kn...@digia.com wrote: On 3/18/13 6:36 PM, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 18 de março de 2013 15.18.07, Knoll Lars wrote: We have said that we'll move to time based releases. Should we stop this because we aren't yet good enough in controlling our systems? I don't think so. It might feel unfair to some people, but we've had these discussions about some features missing the deadline every single minor release. Now if there are one or two features that are vital to make Qt 5.1 possible, we can discuss exceptions for those. But then we need to make sure they go in in the next two days. Which features would these be? I know of only the QUrlPathInfo and the timezone features, plus minor API changes, for QtCore. The former is something that had been lost in my large dashboard until last week, and John's changes were too big to review while I was at a conference. Yes. I doubt we'll get timezone done in time though, unless you're happy with the API as it is now. The file selectors would be very helpful for declarative. Getting it in is important, because I'd like to set the standard before everybody does his own. I think BlackBerry might also need it to move over to Qt 5 at some point BlackBerry kind of needs it, in that if they don't have it then they'll continue to do their own highly incompatible thing after switching to Qt 5. Which is bad enough for everyone that we can say it's needed. My current concern with QFileSelectors is the discussion. There was a discussion on the mailing list months ago where everyone involved came to a rough consensus. Unfortunately it appears that not all interested parties were involved in this discussion, so we get to go through it again now in gerrit. In these circumstances, should the discussion move back to the ML? Or do we move the conversation to the review comments and assume interested parties are watching the change? In either case, how can we give the discussion enough time when it sparks back up right before merge? -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QA] Suggestion -- Bug Reports' Assignment
On Wed, Mar 13, 2013 at 5:43 AM, Jason McDonald macadd...@gmail.com wrote: On Tue, Mar 12, 2013 at 11:27 PM, Motyka Rafal rafal.mot...@digia.com wrote: Hello, I want to express another suggestions for bug management: - A newly opened bug report shouldn't be automatically assigned to anyone. - Logged-in users should be able to assign bug reports to themselves. Assigned = 'someone works or is going to work on the item' Unassigned = 'nobody works on the item' I'm not fond of this distinction because it's not very practical. I have plenty of low priority bugs assigned to me which I'm intending to fix sometime. Does this count as someone is going to work on the item? Because it's certainly viable for someone else to take over if they wanted it done sooner than sometime, just as viable as an unassigned bug. But there's the advantage that they know who to ask if they have questions about the task. I much prefer the distinction like Thiago suggested, where assignee is a person responsible for the bug even if they aren't necessarily going to ever find time to work on the item. At least then you have someone to ask if you want to take it over but have questions. Please feel free to comment on this. If there are no serious objections, this change will be introduced soon. The impact of the change will be evaluated. I think that this is something that can be decided by each module maintainer. I disagree, because JIRA is supposed to be a tool that allows the different groups to work together. It's going to be confusing for even dedicated triagers to follow a variety of conflicting rules, and it certainly can't be asked of the bug reporters (who don't want to need special training based on the component which they're bad at picking anyways...). Even if the default assignee is Unassigned for some modules, the meaning of assigned vs unassigned should be consistent throughout the Qt project. Personally, I'm happy to have testlib bugs auto-assigned to me so that I get an email for each new bug to prompt me to go and triage it. I prefer the email notification to having to poll Jira frequently. The volume of new bug reports in testlib is low enough that this works well for me. I also happen to be the default assignee of the Other component and getting those bugs auto-assigned to me prompts me via email to have a look and figure out which component the Other bugs really belong to. Unless I mark something as In Progress, I'm happy for anybody else to take it off my hands by assigning it to themselves. On the other hand, I can see that maintainers with a larger throughout of Jira tasks might prefer to default to Unassigned and poll Jira for high-priority items. Jira supports both options on a per-component basis, so we can be flexible. Except that you need to triage the bugs *before* you can be confident in the component or priority, so that approach doesn't work. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Starting preparations for Qt 5.1
Don't you mean Mac and Windows? I thought X11 was added a while ago. -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com On Mar 18, 2013, at 12:05 PM, Knoll Lars lars.kn...@digia.com wrote: On 3/18/13 4:58 PM, Laszlo Papp lp...@kde.org wrote: On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire thomas.mcgu...@kdab.com wrote: QtSensors needs to be added to qt5.git, but couldn't yet, due to CI failures. See https://codereview.qt-project.org/#change,48905. + QtSerialPort: https://codereview.qt-project.org/#change,49157 + Mac and X11 extras. Yes, these are known. In addition, we need to get qt5.git updated to recent sha1's of all qt modules. Cheers, Lars ___ 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] [Releasing] Starting preparations for Qt 5.1
On segunda-feira, 18 de março de 2013 19.31.03, Knoll Lars wrote: I know of only the QUrlPathInfo and the timezone features, plus minor API changes, for QtCore. The former is something that had been lost in my large dashboard until last week, and John's changes were too big to review while I was at a conference. Yes. I doubt we'll get timezone done in time though, unless you're happy with the API as it is now. I'll do my best to review it. The file selectors would be very helpful for declarative. Getting it in is important, because I'd like to set the standard before everybody does his own. I think BlackBerry might also need it to move over to Qt 5 at some point I delegated that because I had no time. Therefore, I will abide by the decisions of whoever did review it. I would still like it work for the Mac HighDPI functionality and work with QFile. I don't want a class in QtCore that can't be used with other QtCore classes directly. in fact, thiago and me already decided that we'll create an old/5.0 branch from stable right before we merge dev. Not that I'm principally opposed to this, but please remember proper process: These should at least get discussed on this ML, not just get decided by two people and then announced. I thought it was discussed on the mailing list. Ok, I might have missed it. The way Ossi put it, it sounded like an IRC discussion. He surprised me too. And if it was an IRC conclusion, he could have said we came to the conclusion that creating old/5.0 is a good idea. -- 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] [QA] Suggestion -- Bug Reports' Assignment
On segunda-feira, 18 de março de 2013 14.39.14, Alan Alpert wrote: I'm not fond of this distinction because it's not very practical. I have plenty of low priority bugs assigned to me which I'm intending to fix sometime. Does this count as someone is going to work on the item? Because it's certainly viable for someone else to take over if they wanted it done sooner than sometime, just as viable as an unassigned bug. But there's the advantage that they know who to ask if they have questions about the task. I much prefer the distinction like Thiago suggested, where assignee is a person responsible for the bug even if they aren't necessarily going to ever find time to work on the item. At least then you have someone to ask if you want to take it over but have questions. Wait, wait. I never suggested that long-term. I am ok with having a default assignee, who is responsible for *triaging* the bug. As soon as the triaging is complete, you can unassign. I highly recommend that you keep yourself in the Watchers list after you unassign. I do that too, unless I reassigned to a very different domain (like Core: Event System - GUI: Window Management). I do that and would like to continue doing that. One thing I hate is to have a very long dashboard, which is the same thing as not having a dashboard. The very long Gerrit dashboard is definitely impacting my efficiency -- and everyone who depends on me is suffering. Please don't force me to have a very long dashboard in JIRA too, it will just mean I won't look at JIRA, ever. I disagree, because JIRA is supposed to be a tool that allows the different groups to work together. It's going to be confusing for even dedicated triagers to follow a variety of conflicting rules, and it certainly can't be asked of the bug reporters (who don't want to need special training based on the component which they're bad at picking anyways...). Even if the default assignee is Unassigned for some modules, the meaning of assigned vs unassigned should be consistent throughout the Qt project. Agreed. Personally, I'm happy to have testlib bugs auto-assigned to me so that I get an email for each new bug to prompt me to go and triage it. I prefer the email notification to having to poll Jira frequently. The volume of new bug reports in testlib is low enough that this works well for me. I also happen to be the default assignee of the Other component and getting those bugs auto-assigned to me prompts me via email to have a look and figure out which component the Other bugs really belong to. Unless I mark something as In Progress, I'm happy for anybody else to take it off my hands by assigning it to themselves. On the other hand, I can see that maintainers with a larger throughout of Jira tasks might prefer to default to Unassigned and poll Jira for high-priority items. Jira supports both options on a per-component basis, so we can be flexible. Except that you need to triage the bugs *before* you can be confident in the component or priority, so that approach doesn't work. Agreed too. But doesn't JIRA have a feature that mails you of new activity (including new entries) in a search term? You should be able to watch components and be notified, just as if you had been assigned a new bug. -- 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] [QA] Suggestion -- Bug Reports' Assignment
On Mon, Mar 18, 2013 at 4:01 PM, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 18 de março de 2013 14.39.14, Alan Alpert wrote: I'm not fond of this distinction because it's not very practical. I have plenty of low priority bugs assigned to me which I'm intending to fix sometime. Does this count as someone is going to work on the item? Because it's certainly viable for someone else to take over if they wanted it done sooner than sometime, just as viable as an unassigned bug. But there's the advantage that they know who to ask if they have questions about the task. I much prefer the distinction like Thiago suggested, where assignee is a person responsible for the bug even if they aren't necessarily going to ever find time to work on the item. At least then you have someone to ask if you want to take it over but have questions. Wait, wait. I never suggested that long-term. I am ok with having a default assignee, who is responsible for *triaging* the bug. As soon as the triaging is complete, you can unassign. Sorry for misinterpreting your sentiments. Myself, I think it's better to keep it long term so that there's always a clear point of contact for the task. Since JIRA components do not match cleanly to the maintainers list, and 'assignee' level can be even more accurate than that anyways, and the maintainers list is an additional step removed, I think it's best to have a 'most relevant person' linked to from each task. Even if all they can say about it is No-one's working on that right now, no idea when anyone would. I highly recommend that you keep yourself in the Watchers list after you unassign. I do that too, unless I reassigned to a very different domain (like Core: Event System - GUI: Window Management). I do that and would like to continue doing that. One thing I hate is to have a very long dashboard, which is the same thing as not having a dashboard. The very long Gerrit dashboard is definitely impacting my efficiency -- and everyone who depends on me is suffering. Please don't force me to have a very long dashboard in JIRA too, it will just mean I won't look at JIRA, ever. The difference between JIRA and gerrit here, in my opinion, is that JIRA is much more organizable on an individual basis. My JIRA dashboard is used as a link to various filters for when I'm looking at various tasks. I don't often look at the 'all my assigned issues', since I have more specific filters for common activities (such as triage). This includes being able to look only at tasks with high priority or recent activity, something that would clean up the gerrit dashboard a lot (but shouldn't be added fully-blown to gerrit because it would be immense feature creep). I disagree, because JIRA is supposed to be a tool that allows the different groups to work together. It's going to be confusing for even dedicated triagers to follow a variety of conflicting rules, and it certainly can't be asked of the bug reporters (who don't want to need special training based on the component which they're bad at picking anyways...). Even if the default assignee is Unassigned for some modules, the meaning of assigned vs unassigned should be consistent throughout the Qt project. Agreed. Personally, I'm happy to have testlib bugs auto-assigned to me so that I get an email for each new bug to prompt me to go and triage it. I prefer the email notification to having to poll Jira frequently. The volume of new bug reports in testlib is low enough that this works well for me. I also happen to be the default assignee of the Other component and getting those bugs auto-assigned to me prompts me via email to have a look and figure out which component the Other bugs really belong to. Unless I mark something as In Progress, I'm happy for anybody else to take it off my hands by assigning it to themselves. On the other hand, I can see that maintainers with a larger throughout of Jira tasks might prefer to default to Unassigned and poll Jira for high-priority items. Jira supports both options on a per-component basis, so we can be flexible. Except that you need to triage the bugs *before* you can be confident in the component or priority, so that approach doesn't work. Agreed too. But doesn't JIRA have a feature that mails you of new activity (including new entries) in a search term? You should be able to watch components and be notified, just as if you had been assigned a new bug. Yes, there are multiple ways of searching for untriaged bugs. I'd be happy with any definitive filter that could be used to triage bugs for the component, for which my current one is AssignedUser == Maintainer Priority == Unevaluated. That said, there's also the 'responsible' person aspect to having tasks auto-assigned, as well as the triage aspects. -- Alan Alpert ___ Development mailing list Development@qt-project.org
Re: [Development] Qt for iOS - iOSStyle
On Mar 18, 2013, at 8:26 AM, Mediator Software i...@mediator-software.com wrote: In the real world, Qt on iOS is being used primarily to port existing QtWidget applications to the iPad, not to write new ones (nor to do anything on any other iOS platforms). There is a single customer using QML on iOS, once again porting an existing app. My opinion is that an iOS style for QtWidgets would be a waste of time One man's trash, another man's treasure. Why? Judging from existing Qt apps on iOS, noone is using platform styling anyway. They should. All existing ported apps have custom UIs developed with QtWidgets. They don't look like iOS, fusion or anything else. They have their own UI. Which generally looks out of place and terrible. This includes Apple's stock apps like Notes. I hope Jony Ive gets rid of all this skeumorphic design. See, people argue that there are many Apple stock apps that use totally custom styling, therefore everyone should do that, screw native controls, they don't matter. However there's a decent handful of stock apps that use almost exclusively native styling: Settings, Phone, Messages, Mail, Calendar, Contacts, Safari and at least in my opinion those are some of the most well designed and best looking apps on the system. Not every app should be styled native. Not every app should be styled custom. Some should use a combination of both. It all depends on what's appropriate for the situation at hand. All I'm asking is that people recognize that we need a balance here. We can provide both options. The same goes for QML, but there I can see a use for iOS QML components. So can I. I may work on this in the future as well. Right now the focus is widgets. What we really need a new styling system that can act as a backend for both QStyle/widgets and QML. So what's the problem with making iOS styled QtWidgets? They will never ever look and behave the same as the native components (maybe a button, but how about a list view? And what is a combo box on iOS?). You're safer with a custom UI in that case because Apple will fail you if you confuse the user (if it looks like a UIKit widget it must behave *exactly* like a UIKit widget). They will definitely look the same. As for behave, that's a little harder but it can still be done. A combo box is a UIPickerView. There's no rule that requires a QComboBox to look like a rectangle with a down arrow that pops up a menu when you click it. I think substituting the appearance/behavior of a UIPickerView for QComboBox makes sense as their functional equivalence is roughly the same. There are plenty of comments in the Qt documentation that make note of platform specific exceptions, or a property's lack of effect on one platform or another. iOS may have more of these than other platforms. That's OK. Sometimes it would be nice to use actual UIKit controls in Qt applications (eg. UIWebView), but have them behave like Qt widgets (signals/slots etc.). For Qt4iOS on Qt4 (and soon on Qt5), custom QWidget wrappers have been developed for some UIKit controls. This gives you the *actual* UIKit control (pixel perfect with its exact behaviour), but let's you use Qt layouts/logic etc. IMHO that's the way forward for Qt widget apps that look like UIKit apps. I intend to do something similar with QML (embedding a UIKit control in a QML item). There's no reason why wrappers (C++ or QML) couldn't be developed for all UIKit widgets. There's not that many of them. Yes, this could certainly be useful. It's one option, not the only one. I'd actually like to see more of these on desktop platforms -- especially Mac, since Qt has no QSearchField or QSegmentedControl (we should!), which are quite nice. IMHO, it would be most useful to make QtQuick components for iOS. Someone has already made a set, but it's unclear what their plans are. You can see a demo video here: https://docs.google.com/file/d/0B2qhh3gqs-wzaEJvV3A4TjVTQWc/edit?pli=1 https://docs.google.com/file/d/0B2qhh3gqs-wzXzRlNmdUN0thcTA/edit Almost everything looks wrong. The UISwitch text is misaligned and the fonts on the toolbars look strange. Smells like an attempted custom drawing. Again, I've already started on QIosStyle and it's working pretty nicely. https://codereview.qt-project.org/#change,51167 Once I've uploaded some of the functionality I've been working on, I encourage you to give it a try. It might make you change your mind about QIosStyle being a waste of time. :) -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On segunda-feira, 18 de março de 2013 19.57.41, Jake Thomas Petroules wrote: On Mar 18, 2013, at 8:26 AM, Mediator Software i...@mediator-software.com wrote: In the real world, Qt on iOS is being used primarily to port existing QtWidget applications to the iPad, not to write new ones (nor to do anything on any other iOS platforms). There is a single customer using QML on iOS, once again porting an existing app. My opinion is that an iOS style for QtWidgets would be a waste of time One man's trash, another man's treasure. Why? Judging from existing Qt apps on iOS, noone is using platform styling anyway. They should. No, they shouldn't, not now anyway. If your style work is successful and looks good, then we can say that people should use the widgets. But right now, they definitely should stay away from them! Applications will default to the Fusion style, which is very touch- unfriendly. In any case, we've been trying this for 4 years. QWidgets simply don't work on mobile environments. It was hard enough on platforms that we could reasonably control (the three Nokia platforms). It will be that much more difficult on a platform where we have *no* say in how things behave, has extremely picky users and an arbitrary review before being allowed. What we really need a new styling system that can act as a backend for both QStyle/widgets and QML. Agreed. The question is to find what is common between those. There's almost nothing. Once I've uploaded some of the functionality I've been working on, I encourage you to give it a try. It might make you change your mind about QIosStyle being a waste of time. :) I appreciate your work and wish you success. But please be prepared to accept failure too. -- 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
