[Development] Ongoing testlib maintenance
Along with most of the Brisbane Trolls, I'll be leaving Nokia tomorrow. I'll be on vacation for the next two months, but I will check my gerrit dashboard every few days and try to keep up with reviews. I intend to keep my Maintainer status while I still feel that I can commit enough time to do it justice. I have a few things I still want to add to testlib for 5.1, but how much time I can devote to that will depend on where I end up working when I return to Brisbane. Cheers, -- Jason ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing Tim Jenssen and Niels Weber for Approver Status
I wrote on Friday, August 03, 2012 12:47 PM: To: development@qt-project.org Subject: [Development] Proposing Tim Jenssen and Niels Weber for Approver Status Hello everybody. I hereby propose to grant Tim Jenssen and Niels Weber Approver status in the Qt Project. Tim and Niels have handled a major parts of the development of the Qt Installer Framework and the SDK releases for more than two years now. For reference, see https://codereview.qt-project.org/#q,owner:tim.jenssen%2540nokia.com,n,z and https://codereview.qt-project.org/#q,owner:niels.2.weber%2540nokia.com,n,z Fifteen work days have passed, no objections have been raised. Welcome to your new role ;-) Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Regression / Behavioral Change in QSqlTableModel / QTableView in Qt 5
Thank you for your response! 2012/8/14 Mark Brand mabr...@mabrand.nl: QSqlTableModel has had some major changes for Qt5. The changes file dist/changes-5.0.0 lists them. I totally missed that. ... each edit causes the table to be requeried and the model reset, which breaks navigation in the view. Do you mind elaborating in which way this breaks navigation? It sounds like you are using OnFieldChange or OnRowChange strategy. This is by design. The deleted row remains in the cache until select() is called again. I see. Is there any possibility to update the model (so the row is removed in the view, not just cleared out) without 'resetting' the model using select()? I just want to have the row deleted (yes, at the cost of losing navigation and selection in the view), but without having to repopulate the data from the database (which is implied by select()). Inserations for example using insertRecord() are not reflected as well (no visible changes in the view, although data is added to the table). This is not the expected behavior and I cannot reproduce it. Can you provide an example? I tried to boil down the code to a simple example and I now can nail down the problem. It only affects tables having an AUTOINCREMENT primary key, causing an empty row to be inserted (with an exclamation mark in the view, same as for a deleted row) and a select() is required to get the actual data into the view (and obviously the model as well). Tables having a primary key not beeing AUTOINCREMENT (although they are set by the database as well) seem to be not effected (data is shown immediately). br Maemi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing Orgad Shaneh for Approver status
On Wednesday, August 08, 2012 11:17 AM Hunger Tobias wrote: I am hereby proposing Orgad as an approver for Qt project. As anybody active on Qt Creator will already know, Orgad is helping a lot with bug reports, feature requests, many bug fixes all over the code base, new feature (e.g. in the version management area and other places) as well as lots of code reviews. And... fifteen days passed without an objection being raised: Welcome to your new role, Orgad! Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5 beta
Hi everybody, the Qt 5 beta has now been released. Please find all the details at http://www.qt-project.org/wiki/Qt-5-Beta and my blog post at http://labs.qt.nokia.com/2012/08/30/qt5-beta-is-here Enjoy! Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
Someone wrote: [...] blog post at http://labs.qt.nokia.com/2012/08/30/qt5-beta-is-here A slightly more verbose version is to be found at http://labs.qt.nokia.com/2012/08/30/qt-5-beta-is-here/ Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
On quinta-feira, 30 de agosto de 2012 11.23.07, lars.kn...@nokia.com wrote: Hi everybody, the Qt 5 beta has now been released. Please find all the details at http://www.qt-project.org/wiki/Qt-5-Beta and my blog post at http://labs.qt.nokia.com/2012/08/30/qt5-beta-is-here Enjoy! As pointed out on IRC: it's unacceptable that this release happened without a formal GO/NO-GO in the releasing mailing list and in the #qt-releases channel. There are people testing packages today, right now. We might be missing the Release Manager, recognised by the Qt Project, who makes the call and ensures that everyone's opinions are collected. But that doesn't give someone else the right to release. It simply makes a release impossible. Now the deed is done and let's move on. But let's make sure it never happens again. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden 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] Qt 5 beta
On Thursday, August 30, 2012 13:41:42 Thiago Macieira wrote: On quinta-feira, 30 de agosto de 2012 11.23.07, lars.kn...@nokia.com wrote: Hi everybody, the Qt 5 beta has now been released. Please find all the details at http://www.qt-project.org/wiki/Qt-5-Beta and my blog post at http://labs.qt.nokia.com/2012/08/30/qt5-beta-is-here Enjoy! As pointed out on IRC: it's unacceptable that this release happened without a formal GO/NO-GO in the releasing mailing list and in the #qt-releases channel. There are people testing packages today, right now. We might be missing the Release Manager, recognised by the Qt Project, who makes the call and ensures that everyone's opinions are collected. But that doesn't give someone else the right to release. It simply makes a release impossible. Now the deed is done and let's move on. But let's make sure it never happens again. I agree with all of this. 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 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] Qt 5 beta
On Thursday, August 30, 2012 11:23:07 lars.kn...@nokia.com wrote: Hi everybody, the Qt 5 beta has now been released. Please find all the details at http://www.qt-project.org/wiki/Qt-5-Beta and my blog post at http://labs.qt.nokia.com/2012/08/30/qt5-beta-is-here Enjoy! Lars 1cebd906af95e2c8ae37f1eae4a1c5019640b3b3 has been tagged as v5.0.0-beta1. That is not the correct commit to have that tag. That is the current HEAD commit in master, not the commit that qt5.git uses as a submodule, and not the commit that is in packages. 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 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] Qt 5 beta
On Aug 30, 2012, at 1:41 PM, ext Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 30 de agosto de 2012 11.23.07, lars.kn...@nokia.com wrote: Hi everybody, the Qt 5 beta has now been released. Please find all the details at http://www.qt-project.org/wiki/Qt-5-Beta and my blog post at http://labs.qt.nokia.com/2012/08/30/qt5-beta-is-here Enjoy! As pointed out on IRC: it's unacceptable that this release happened without a formal GO/NO-GO in the releasing mailing list and in the #qt-releases channel. There are people testing packages today, right now. We might be missing the Release Manager, recognised by the Qt Project, who makes the call and ensures that everyone's opinions are collected. But that doesn't give someone else the right to release. I have actually talked with quite a few people before making the call. Given that we don't currently have a recognised release manager I took that onto me. I agree we need to make this transparent though, and I'll make sure that happens for the next one. Lars It simply makes a release impossible. Now the deed is done and let's move on. But let's make sure it never happens again. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden ___ 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] Qt 5 beta
On 08/30/2012 01:48 PM, ext Stephen Kelly wrote: 1cebd906af95e2c8ae37f1eae4a1c5019640b3b3 has been tagged as v5.0.0-beta1. That is not the correct commit to have that tag. That is the current HEAD commit in master, not the commit that qt5.git uses as a submodule, and not the commit that is in packages. Thanks, Hi, The tag in qtbase should be updated now. It points to 62b0f41ae0c2971db5d6e53972d746b0a865a736 Cheers, -- Sergio Ahumada ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] HELP NEEDED: Cleaning up the class documentation for Qt 5
Hi, We've started looking at cleaning up the documentation to make it more consistent with the changes made in Qt 5. One big task is handling the class reference documentation. Since this was originally written when widgets were the only way to write GUIs in Qt, some of the documentation is rather widget-centric in how it presents things. There might also be other content in there that is no longer correct, or less relevant, with the changes made in Qt 5. The only way to do this is really to go through the classes one by one. We need to actually read the documentation for each class to make sure it still makes sense and presents Qt in a way that give people the information they need. I'm hoping the maintainers of classes have the time to go through the classes they own, and if anyone else wants to step up and handle any unclaimed classes, we'll be very thankful for the effort. To organize the work, we've made a wiki-page: http://qt-project.org/wiki/Qt5ClassDocumentationCleanUp If you want to help out, please edit the page and replace unassigned with your name next to the class you're claiming to avoid duplicate work. If the class requires patching, please make sure the change is actually merged before you mark the class as done. Thanks! -- Eskil, Paul and Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
ext Thiago Macieira wrote on 2012-08-30: On quinta-feira, 30 de agosto de 2012 11.23.07, lars.kn...@nokia.com wrote: Hi everybody, the Qt 5 beta has now been released. Please find all the details at http://www.qt-project.org/wiki/Qt-5-Beta and my blog post at http://labs.qt.nokia.com/2012/08/30/qt5-beta-is-here Enjoy! As pointed out on IRC: it's unacceptable that this release happened without a formal GO/NO-GO in the releasing mailing list and in the #qt-releases channel. There are people testing packages today, right now. We might be missing the Release Manager, recognised by the Qt Project, who makes the call and ensures that everyone's opinions are collected. But that doesn't give someone else the right to release. It simply makes a release impossible. Now the deed is done and let's move on. But let's make sure it never happens again. Agreed. The latest test of the windows source package was reported as a failure (by J-P Nurmi), so the beta might not even work for win32-msvc2010 mkspec. Jan Arve ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
Greetings all, Le 30/08/2012 13:23, lars.kn...@nokia.com a écrit : the Qt 5 beta has now been released. Please find all the details at http://www.qt-project.org/wiki/Qt-5-Beta and my blog post at http://labs.qt.nokia.com/2012/08/30/qt5-beta-is-here Enjoy! Trying to compile on Windows 7 64bits using MSVC 2010 (32bits compiler). After having read the provided README. D:\qt\qt5-5.0.0-win32-msvc2010configure -help + D:/qt/qt5-5.0.0-win32-msvc2010/qtbase/configure -help Please wait while bootstrapping configure ... Microsoft (R) Program Maintenance Utility Version 10.00.30319.01 Copyright (C) Microsoft Corporation. All rights reserved. cl -c -Yc -nologo -Zm200 -Zc:wchar_t -MT -W3 -GR -EHsc -w34100 -w34189 -DUNICODE -DQT_NO_CODECS -DQT_NO_TEXTCODEC -DQT_NO_UNICODETABLES -DQT_LITE_COMPO NENT -DQT_NO_COMPRESS -DQT_NO_THREAD -DQT_NO_QOBJECT -DQT_NO_GEOM_VARIANT -D_CRT_SECURE_NO_DEPRECATE -DQT_BOOTSTRAPPED -DCOMMERCIAL_VERSION -I..\..\include -I ..\..\include\QtCore -I..\..\include\QtCore\5.0.0 -I..\..\include\QtCore\5.0.0\QtCore -ID:\qt\qt5-5.0.0-win32-msvc2010\qtbase\tools\shared -ID:\qt\qt5- 5.0.0-win32-msvc2010\qtbase\mkspecs\win32-msvc2008 -Fpconfigure_pch.pch -Foconfigure_pch.obj -TP D:\qt\qt5-5.0.0-win32-msvc2010\qtbase\tools\configure\configur e_pch.h configure_pch.h D:\qt\qt5-5.0.0-win32-msvc2010\qtbase\tools\configure\configure_pch.h(49) : fatal error C1083: Cannot open include file: 'qlist.h': No such file or directory NMAKE : fatal error U1077: 'C:\vs10\VC\BIN\cl.EXE' : return code '0x2' Stop. *** qtbase/configure exited with non-zero status. ...and some others, missing QtCore/qalgorithms.h... - Added to -I..\..\src\corelib\tools to EXTRA_CXXFLAGS - Changed ...\qtbase\src\corelib\tools\qlist.h to #include qalgorithms.h instead of QtCore/qalgorithms.h ...and more errors like those ones... Giving up for now. However if someone want me to try something I'll be glad to try, I just don't have time to dig myself. *sigh* -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
ext Yves Bailly wrote on 2012-08-30: Greetings all, Le 30/08/2012 13:23, lars.kn...@nokia.com a écrit : the Qt 5 beta has now been released. Please find all the details at http://www.qt-project.org/wiki/Qt-5-Beta and my blog post at http://labs.qt.nokia.com/2012/08/30/qt5-beta-is-here Enjoy! Trying to compile on Windows 7 64bits using MSVC 2010 (32bits compiler). After having read the provided README. D:\qt\qt5-5.0.0-win32-msvc2010configure -help + D:/qt/qt5-5.0.0-win32-msvc2010/qtbase/configure -help Please wait while bootstrapping configure ... Microsoft (R) Program Maintenance Utility Version 10.00.30319.01 Copyright (C) Microsoft Corporation. All rights reserved. cl -c -Yc -nologo -Zm200 -Zc:wchar_t -MT -W3 -GR -EHsc -w34100 -w34189 -DUNICODE -DQT_NO_CODECS -DQT_NO_TEXTCODEC - DQT_NO_UNICODETABLES -DQT_LITE_COMPO NENT -DQT_NO_COMPRESS - DQT_NO_THREAD -DQT_NO_QOBJECT -DQT_NO_GEOM_VARIANT - D_CRT_SECURE_NO_DEPRECATE -DQT_BOOTSTRAPPED -DCOMMERCIAL_VERSION - I..\..\include -I ..\..\include\QtCore - I..\..\include\QtCore\5.0.0 -I..\..\include\QtCore\5.0.0\QtCore -ID:\qt\qt5-5.0.0-win32-msvc2010\qtbase\tools\shared -ID:\qt\qt5- 5.0.0-win32-msvc2010\qtbase\mkspecs\win32-msvc2008 - Fpconfigure_pch.pch -Foconfigure_pch.obj -TP D:\qt\qt5-5.0.0-win32- msvc2010\qtbase\tools\configure\configur e_pch.h configure_pch.h D:\qt\qt5-5.0.0-win32- msvc2010\qtbase\tools\configure\configure_pch.h(49) : fatal error C1083: Cannot open include file: 'qlist.h': No such file or directory NMAKE : fatal error U1077: 'C:\vs10\VC\BIN\cl.EXE' : return code '0x2' Stop. *** qtbase/configure exited with non-zero status. ...and some others, missing QtCore/qalgorithms.h... - Added to -I..\..\src\corelib\tools to EXTRA_CXXFLAGS - Changed ...\qtbase\src\corelib\tools\qlist.h to #include qalgorithms.h instead of QtCore/qalgorithms.h ...and more errors like those ones... Giving up for now. However if someone want me to try something I'll be glad to try, I just don't have time to dig myself. *sigh* configure.bat will run perl. Please check if it will use the ActiveState perl, and not the perl shipped with msysgit. I always put the ActiveState perl directory as the first path in %PATH% in order to avoid this. Jan Arve ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
Le 30/08/2012 14:43, jan-arve.saet...@nokia.com a écrit : ext Yves Bailly wrote on 2012-08-30: configure.bat will run perl. Please check if it will use the ActiveState perl, and not the perl shipped with msysgit. I always put the ActiveState perl directory as the first path in %PATH% in order to avoid this. I guess it's actually ActiveState's Perl indeed: D:\qtperl --version This is perl 5, version 14, subversion 2 (v5.14.2) built for MSWin32-x64-multi-thread (with 1 registered patch, see perl -V for more detail) Copyright 1987-2011, Larry Wall Binary build 1402 [295342] provided by ActiveState http://www.ActiveState.com Built Oct 7 2011 15:19:36 Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using man perl or perldoc perl. If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 Visual Studio Add-in 1.2.0 Beta
Hi Ismo, we noticed that the pretty printers for the debugger are not updated to the Qt5 Datatypes. So its not possible to introspect eg QString. Will this happen somewhen? Thank you Andy Am 30.08.2012 15:04, schrieb Haataja Ismo: Hi, Thank you Kevin! There is now an updated installer where this problem should be solved. http://origin.releases.qt-project.org/digia_vsaddin/ BR, Ismo -Original Message- From: Kevin Funk [mailto:kevin.f...@kdab.com] Sent: 30. elokuuta 2012 10:22 To: development@qt-project.org Cc: Haataja Ismo Subject: Re: [Development] Qt5 Visual Studio Add-in 1.2.0 Beta Hey, while installing the add-in I get the following issue: Extract: qt5appwrapper.exe Output folder: C:\Program Files (x86)\Digia\Qt5VSAddin\help Registering C:\Program Files (x86)\Digia\Qt5VSAddin\q5makewrapper1.dll... Failed to load platform plugin windows. Available platforms are: Registering of C:\Program Files (x86)\Digia\Qt5VSAddin\q5makewrapper1.dll failed! (errorcode: 1) Installation continues, however. I guess you are missing the platform plugin DLL? -- Andreas Holzammer | andreas.holzam...@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 smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
On Thursday, August 30, 2012 01:41:42 PM ext Thiago Macieira wrote: [...] Now the deed is done and let's move on. But let's make sure it never happens again. Sounds right. I hope everyone also agrees that it's time to celebrate! We've come a bloody long way since the Alpha. If we keep up the pace perhaps we can make another release soon, which will fix many of the glitches of this beta. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
On 30.8.2012 16.20, Simon Hausmann simon.hausm...@nokia.com wrote: I hope everyone also agrees that it's time to celebrate! We've come a bloody long way since the Alpha. +1 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HELP NEEDED: Cleaning up the class documentation for Qt 5
Hello, Torsdag 30. august 2012 12.21.40 skrev eskil.abrahamsen-blomfe...@nokia.com: Hi, We've started looking at cleaning up the documentation to make it more consistent with the changes made in Qt 5. One big task is handling the class reference documentation. Since this was originally written when widgets were the only way to write GUIs in Qt, some of the documentation is rather widget-centric in how it presents things. There might also be other content in there that is no longer correct, or less relevant, with the changes made in Qt 5. The only way to do this is really to go through the classes one by one. We need to actually read the documentation for each class to make sure it still makes sense and presents Qt in a way that give people the information they need. I'm hoping the maintainers of classes have the time to go through the classes they own, and if anyone else wants to step up and handle any unclaimed classes, we'll be very thankful for the effort. To organize the work, we've made a wiki-page: http://qt-project.org/wiki/Qt5ClassDocumentationCleanUp If you want to help out, please edit the page and replace unassigned with your name next to the class you're claiming to avoid duplicate work. If the class requires patching, please make sure the change is actually merged before you mark the class as done. Great stuff :) Jedrzej and I just started running our qdoc bot, similar to the sanity bot. It will post on commits where we suspect new documentation errors to be introduces. Let us know when it doesn't work. Currently it runs make docs in qtbase with patches that have been pushed and their parent commit to compare the difference in output. As for the documentation, there are some points to keep in mind: We have quite a few broken links, those are sometimes not easy to fix, try doing the easy fixes first, such as a function not having documentation. For examples we propose a new structure (talking to several people in Oslo). One problem we are facing when trying to fix links is that we currently have so many different places where the documentation can be found. We might long term put the docs next to the actual example, but that's a longer discussion. For the short term I'd like to propose this organisation for qtbase examples: For QtGui: qtbase/examples/gui/myguiexample/ code.cpp/h/... and the gui example documentation: qtbase/examples/gui/doc/myguiexample.qdoc QtWidgets: qtbase/examples/gui/mywidgetexample/ code.cpp/h/... and the widget example documentation: qtbase/examples/gui/doc/mywidgetexample.qdoc and of course the same for the other modules' examples. If we move the examples first, fixing links makes more sense. Greetings Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HELP NEEDED: Cleaning up the class documentation for Qt 5
Gladhorn Frederik (Nokia-MP/Oslo) wrote on 2012-08-30: Hello, Torsdag 30. august 2012 12.21.40 skrev eskil.abrahamsen- blomfe...@nokia.com: Hi, We've started looking at cleaning up the documentation to make it more consistent with the changes made in Qt 5. One big task is handling the class reference documentation. Since this was originally written when widgets were the only way to write GUIs in Qt, some of the documentation is rather widget-centric in how it presents things. There might also be other content in there that is no longer correct, or less relevant, with the changes made in Qt 5. The only way to do this is really to go through the classes one by one. We need to actually read the documentation for each class to make sure it still makes sense and presents Qt in a way that give people the information they need. I'm hoping the maintainers of classes have the time to go through the classes they own, and if anyone else wants to step up and handle any unclaimed classes, we'll be very thankful for the effort. To organize the work, we've made a wiki-page: http://qt- project.org/wiki/Qt5ClassDocumentationCleanUp If you want to help out, please edit the page and replace unassigned with your name next to the class you're claiming to avoid duplicate work. If the class requires patching, please make sure the change is actually merged before you mark the class as done. Great stuff :) Jedrzej and I just started running our qdoc bot, similar to the sanity bot. It will post on commits where we suspect new documentation errors to be introduces. Let us know when it doesn't work. Currently it runs make docs in qtbase with patches that have been pushed and their parent commit to compare the difference in output. As for the documentation, there are some points to keep in mind: We have quite a few broken links, those are sometimes not easy to fix, try doing the easy fixes first, such as a function not having documentation. For examples we propose a new structure (talking to several people in Oslo). One problem we are facing when trying to fix links is that we currently have so many different places where the documentation can be found. We might long term put the docs next to the actual example, but that's a longer discussion. For the short term I'd like to propose this organisation for qtbase examples: For QtGui: qtbase/examples/gui/myguiexample/ code.cpp/h/... and the gui example documentation: qtbase/examples/gui/doc/myguiexample.qdoc QtWidgets: qtbase/examples/gui/mywidgetexample/ code.cpp/h/... and the widget example documentation: qtbase/examples/gui/doc/mywidgetexample.qdoc Correction - it should be: QtWidgets: qtbase/examples/widgets/mywidgetexample/ code.cpp/h/... and the widget example documentation: qtbase/examples/widgets/doc/mywidgetexample.qdoc Jan Arve ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
On quinta-feira, 30 de agosto de 2012 15.20.33, Simon Hausmann wrote: If we keep up the pace perhaps we can make another release soon, which will fix many of the glitches of this beta. I'm all for making more periodic releases. Congrats to everyone who has put effort into making this happen. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden 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
[Development] Choosing a new MinGW for Qt 5
Hi, I'd like to get this on the table again: What is the MinGW package that we want to support officially? The matrix for Qt 5.0 right now says MinGW gcc 4.5 32 bit [1]. Note that when you're installing latest mingw from mingw.org it's already installing gcc 4.7, and I guess you'd need to dig into the archive to get gcc 4.5 ... But anyway, it's still 32 bit only. In the last days I gave the following packages that also support both 32 bit and 64 bit a try: TDM-GCC: Nice installer, but somewhat stale (gcc 4.6.1 / gdb 7.3.1) + not much (visible) activity Mingw-64: last official 1.0 build is from a year ago (gcc 4.5.4). There are popular, 'semi-official' personal builds with 4.7.1 though ... Mingw-builds: gcc-4.7.1, gdb 7.4.1. packages for gcc-7.4.2 are already in the prerelease directory ... One might think that the only difference in these packages is the gcc version, but this isn't the truth. They also deviate e.g. in the COM headers, which can easily lead to build breakages ... That's why I think it's important to promote _one_ mingw 64 bit package as the officially supported one, and ideally even get it CI tested. After trying all, I agree with Marius that mingw-builds seems a good choice. Qt 5 beta compiled out of the box for me with one minor patch [3] ... So, I think we have a couple of choices here: * We could just add mingw-builds gcc 4.7.1 64 bit to the list of tier 1 configurations, keeping mingw gcc 4.5 32 bit as reference platform. + no changes after beta for reference platforms - two different compilers are more work to test * We could try to make both mingw-builds gcc 4.7.1 64 bit and 32 bit a tier one platform, and get rid of the Mingw from http://www.mingw.org/ + The same toolchain can be tested for 32 bit and 64 bit - 5.0 beta is already out - gcc from mingw.org is probably more wide spread/better tested than mingw-builds * We could leave it as it is, with no recent mingw compiler to easily install, and no 64 bit one Opinions? Note that at the moment we don't test MinGW at all in the CI system [2]. Regards Kai [1]: Official platform matrix: http://qt-project.org/wiki/Qt_5.0#ed49a36c4fd547e5e2ace11bef4f21cf [2]: CI system needs to build with MinGW on Windows: https://bugreports.qt-project.org/browse/QTQAINFRA-549 [3]: Codecs: Fix compilation on MinGW if configure detects iconv: https://codereview.qt-project.org/#change,33936 -Original Message- From: development-bounces+kai.koehne=nokia@qt-project.org [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On Behalf Of Storm-Olsen Marius (Nokia-MP/Austin) Sent: Friday, April 20, 2012 1:54 PM To: pgqui...@elpauer.org Cc: development@qt-project.org Subject: Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK Now wait a minute, I never said such a thing. I said that the MinGW-w64 binaries are Cygwin-based now. Meaning, the MinGW they release needs Cygwin DLLs to run. The output they generate is still native Win32 binaries, which does _not_ require Cygwin. (Anything else would be silly, since you could then just use the normal Cygwin-provided gcc, and not MinGW.) Now, I do see that the latest official release actually comes from the personal(!) build directory of a Ray Linn, and does not require Cygwin. (I only noticed it when looking at the files page, and it says Looking for the latest version? Download mingw-w64-gcc-4.6.3-runtime-2.0.1-static-ada- 20120321.7z (28.2 MB), which happens to point to http://sourceforge.net/projects/mingw- w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/ray_linn/) But personally I much better like the structure, consistency, and variety of the mingwbuilds project. You have to admit looking at http://sourceforge.net/projects/mingwbuilds/files/windows-host/ it feels much cleaner and professional. The MinGW-w64 project _feels_ as if it doesn't have a clear mission. (I'm not saying they don't have one.) -- .marius On 20/04/2012 06:09, ext Pau Garcia i Quiles wrote: Hi, I'd say you are confusing mingw-w64 is available in Cygwin (like mingw.org is) with mingw-w64-produced binaries need Cygwin DLLs. I've been using mingw-w64 for zsync on Windows ( https://www.assembla.com/spaces/zsync-windows ) for quite some time and the zsync.exe and zysncmake.exe binaries work without Cygwin DLLs. On Fri, Apr 20, 2012 at 12:46 PM,marius.storm-ol...@nokia.com wrote: Take another look. They haven't produced pure MinGW binary releases since the end of 2011. The front page says The mingw-w64 toolchain has been officially added to Cygwin mirrors, and when you look under the Releases (and then under Automated Builds) section to the left on the front page, you will see that only Cygwin-based binaries (and linux-based cross-compilers) are now being produced. And yes, if you run 'depends' on those binaries, they do require the Cygwin DLLs. I'm sure you
Re: [Development] Choosing a new MinGW for Qt 5
Sorry people, my email got a bit convoluted. This happens when you add stuff over time ... The gist is: You can't get MinGW gcc 4.5 bit 32 bit easily anymore. We could upgrade the reference platform to gcc 4.7 32 bit. Can we do this even after the beta? If so, can we also add a mingw 64 bit (e.g. from mingw-builds), be it as a reference or tier 1 platform? Regards Kai -Original Message- From: development-bounces+kai.koehne=nokia@qt-project.org [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On Behalf Of Koehne Kai (Nokia-MP/Berlin) Sent: Thursday, August 30, 2012 4:57 PM To: Storm-Olsen Marius (Nokia-MP/Austin); pgqui...@elpauer.org Cc: development@qt-project.org Subject: [Development] Choosing a new MinGW for Qt 5 Hi, I'd like to get this on the table again: What is the MinGW package that we want to support officially? The matrix for Qt 5.0 right now says MinGW gcc 4.5 32 bit [1]. Note that when you're installing latest mingw from mingw.org it's already installing gcc 4.7, and I guess you'd need to dig into the archive to get gcc 4.5 ... But anyway, it's still 32 bit only. In the last days I gave the following packages that also support both 32 bit and 64 bit a try: TDM-GCC: Nice installer, but somewhat stale (gcc 4.6.1 / gdb 7.3.1) + not much (visible) activity Mingw-64: last official 1.0 build is from a year ago (gcc 4.5.4). There are popular, 'semi-official' personal builds with 4.7.1 though ... Mingw-builds: gcc-4.7.1, gdb 7.4.1. packages for gcc-7.4.2 are already in the prerelease directory ... One might think that the only difference in these packages is the gcc version, but this isn't the truth. They also deviate e.g. in the COM headers, which can easily lead to build breakages ... That's why I think it's important to promote _one_ mingw 64 bit package as the officially supported one, and ideally even get it CI tested. After trying all, I agree with Marius that mingw-builds seems a good choice. Qt 5 beta compiled out of the box for me with one minor patch [3] ... So, I think we have a couple of choices here: * We could just add mingw-builds gcc 4.7.1 64 bit to the list of tier 1 configurations, keeping mingw gcc 4.5 32 bit as reference platform. + no changes after beta for reference platforms - two different compilers are more work to test * We could try to make both mingw-builds gcc 4.7.1 64 bit and 32 bit a tier one platform, and get rid of the Mingw from http://www.mingw.org/ + The same toolchain can be tested for 32 bit and 64 bit - 5.0 beta is already out - gcc from mingw.org is probably more wide spread/better tested than mingw-builds * We could leave it as it is, with no recent mingw compiler to easily install, and no 64 bit one Opinions? Note that at the moment we don't test MinGW at all in the CI system [2]. Regards Kai [1]: Official platform matrix: http://qt- project.org/wiki/Qt_5.0#ed49a36c4fd547e5e2ace11bef4f21cf [2]: CI system needs to build with MinGW on Windows: https://bugreports.qt- project.org/browse/QTQAINFRA-549 [3]: Codecs: Fix compilation on MinGW if configure detects iconv: https://codereview.qt-project.org/#change,33936 -Original Message- From: development-bounces+kai.koehne=nokia@qt-project.org [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On Behalf Of Storm-Olsen Marius (Nokia-MP/Austin) Sent: Friday, April 20, 2012 1:54 PM To: pgqui...@elpauer.org Cc: development@qt-project.org Subject: Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK Now wait a minute, I never said such a thing. I said that the MinGW-w64 binaries are Cygwin-based now. Meaning, the MinGW they release needs Cygwin DLLs to run. The output they generate is still native Win32 binaries, which does _not_ require Cygwin. (Anything else would be silly, since you could then just use the normal Cygwin-provided gcc, and not MinGW.) Now, I do see that the latest official release actually comes from the personal(!) build directory of a Ray Linn, and does not require Cygwin. (I only noticed it when looking at the files page, and it says Looking for the latest version? Download mingw-w64-gcc-4.6.3-runtime-2.0.1-static-ada- 20120321.7z (28.2 MB), which happens to point to http://sourceforge.net/projects/mingw- w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/ray_linn/) But personally I much better like the structure, consistency, and variety of the mingwbuilds project. You have to admit looking at http://sourceforge.net/projects/mingwbuilds/files/windows-host/ it feels much cleaner and professional. The MinGW-w64 project _feels_ as if it doesn't have a clear mission. (I'm not saying they don't have one.) -- .marius On 20/04/2012 06:09, ext Pau Garcia i Quiles wrote: Hi, I'd say you are confusing mingw-w64 is available in
[Development] CMake for Qt5: Does exist set(CMAKE_AUTOUIC ON) support? or plan?
set(CMAKE_AUTOMOC ON) is great. But for now I have to use qt5_wrap_ui macros. e.g. cmake_minimum_required(VERSION 2.8.9 FATAL_ERROR) project(testproject) # Find includes in corresponding build directories set(CMAKE_INCLUDE_CURRENT_DIR ON) # Instruct CMake to run moc automatically when needed set(CMAKE_AUTOMOC ON) # Find the QtWidgets library find_package(Qt5Widgets REQUIRED) # Tell CMake to create the helloworld executable add_executable(helloworld main.cpp mainwindow.cpp mainwindow.ui ) # Use the Widgets module from Qt 5 qt5_use_modules(helloworld Widgets) # Support UI files qt5_wrap_ui(ui_mainwindow.h mainwindow.ui) Any help? Thanks! -- Best Regards Yuchen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
Hi, On Thu, Aug 30, 2012 at 4:56 PM, kai.koe...@nokia.com wrote: Hi, I'd like to get this on the table again: What is the MinGW package that we want to support officially? The matrix for Qt 5.0 right now says MinGW gcc 4.5 32 bit [1]. Note that when you're installing latest mingw from mingw.org it's already installing gcc 4.7, and I guess you'd need to dig into the archive to get gcc 4.5 ... But anyway, it's still 32 bit only. In the last days I gave the following packages that also support both 32 bit and 64 bit a try: TDM-GCC: Nice installer, but somewhat stale (gcc 4.6.1 / gdb 7.3.1) + not much (visible) activity Mingw-64: last official 1.0 build is from a year ago (gcc 4.5.4). There are popular, 'semi-official' personal builds with 4.7.1 though ... Mingw-builds: gcc-4.7.1, gdb 7.4.1. packages for gcc-7.4.2 are already in the prerelease directory ... [...] There are more differences than that. There are differences in features, such as threading support, large-file support, etc. Mingw-w64 is usually ahead of any other in terms of features. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
Rubens release is currently broken, and there shouldn't be a need for a separate package for 32bit vs 64bit really. -- .marius On 30/08/2012 10:05, ext Loaden wrote: I want to say, mingw-w64 is the best choice. I am using ruben's personally build to compilation Qt5/QtCreator on both Windows and Linux OS, and it works well! 2012/8/30 kai.koe...@nokia.com mailto:kai.koe...@nokia.com Hi, I'd like to get this on the table again: What is the MinGW package that we want to support officially? The matrix for Qt 5.0 right now says MinGW gcc 4.5 32 bit [1]. Note that when you're installing latest mingw from mingw.org http://mingw.org it's already installing gcc 4.7, and I guess you'd need to dig into the archive to get gcc 4.5 ... But anyway, it's still 32 bit only. In the last days I gave the following packages that also support both 32 bit and 64 bit a try: TDM-GCC: Nice installer, but somewhat stale (gcc 4.6.1 / gdb 7.3.1) + not much (visible) activity Mingw-64: last official 1.0 build is from a year ago (gcc 4.5.4). There are popular, 'semi-official' personal builds with 4.7.1 though ... Mingw-builds: gcc-4.7.1, gdb 7.4.1. packages for gcc-7.4.2 are already in the prerelease directory ... One might think that the only difference in these packages is the gcc version, but this isn't the truth. They also deviate e.g. in the COM headers, which can easily lead to build breakages ... That's why I think it's important to promote _one_ mingw 64 bit package as the officially supported one, and ideally even get it CI tested. After trying all, I agree with Marius that mingw-builds seems a good choice. Qt 5 beta compiled out of the box for me with one minor patch [3] ... So, I think we have a couple of choices here: * We could just add mingw-builds gcc 4.7.1 64 bit to the list of tier 1 configurations, keeping mingw gcc 4.5 32 bit as reference platform. + no changes after beta for reference platforms - two different compilers are more work to test * We could try to make both mingw-builds gcc 4.7.1 64 bit and 32 bit a tier one platform, and get rid of the Mingw from http://www.mingw.org/ + The same toolchain can be tested for 32 bit and 64 bit - 5.0 beta is already out - gcc from mingw.org http://mingw.org is probably more wide spread/better tested than mingw-builds * We could leave it as it is, with no recent mingw compiler to easily install, and no 64 bit one Opinions? Note that at the moment we don't test MinGW at all in the CI system [2]. Regards Kai [1]: Official platform matrix: http://qt-project.org/wiki/Qt_5.0#ed49a36c4fd547e5e2ace11bef4f21cf [2]: CI system needs to build with MinGW on Windows: https://bugreports.qt-project.org/browse/QTQAINFRA-549 [3]: Codecs: Fix compilation on MinGW if configure detects iconv: https://codereview.qt-project.org/#change,33936 -Original Message- From: development-bounces+kai.koehne=nokia@qt-project.org mailto:nokia@qt-project.org [mailto:development-bounces+kai.koehne mailto:development-bounces%2Bkai.koehne=nokia@qt-project.org mailto:nokia@qt-project.org] On Behalf Of Storm-Olsen Marius (Nokia-MP/Austin) Sent: Friday, April 20, 2012 1:54 PM To: pgqui...@elpauer.org mailto:pgqui...@elpauer.org Cc: development@qt-project.org mailto:development@qt-project.org Subject: Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK Now wait a minute, I never said such a thing. I said that the MinGW-w64 binaries are Cygwin-based now. Meaning, the MinGW they release needs Cygwin DLLs to run. The output they generate is still native Win32 binaries, which does _not_ require Cygwin. (Anything else would be silly, since you could then just use the normal Cygwin-provided gcc, and not MinGW.) Now, I do see that the latest official release actually comes from the personal(!) build directory of a Ray Linn, and does not require Cygwin. (I only noticed it when looking at the files page, and it says Looking for the latest version? Download mingw-w64-gcc-4.6.3-runtime-2.0.1-static-ada- 20120321.7z (28.2 MB), which happens to point to http://sourceforge.net/projects/mingw- w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/ray_linn/) But personally I much better like the structure, consistency, and variety of the mingwbuilds project. You have to admit looking at http://sourceforge.net/projects/mingwbuilds/files/windows-host/ it feels much cleaner and professional. The MinGW-w64 project _feels_ as if it
[Development] CMake for Qt5: Cross Compilation for Windows using MinGW-w64
Hi, there!
I am try to cross compilation qt5 apps on Linux.
By this wiki point: http://www.cmake.org/Wiki/CmakeMingw
I can make the simple qt5 demo works.
main.cpp
#include QApplication
#include QLabel
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
QLabel *label = new QLabel(Hello World);
label-show();
int i;
return a.exec();
}
CMakeLists.txt
cmake_minimum_required(VERSION 2.8.9 FATAL_ERROR)
project(testproject)
# Find includes in corresponding build directories
set(CMAKE_INCLUDE_CURRENT_DIR ON)
# Instruct CMake to run moc automatically when needed
set(CMAKE_AUTOMOC ON)
# Find the QtWidgets library
find_package(Qt5Widgets)
# Tell CMake to create the helloworld executable
add_executable(helloworld main.cpp)
# Use the Widgets module from Qt 5
qt5_use_modules(helloworld Widgets)
loaden@qpsoft:~/qpSOFT/Projects/demo/m64$ cmake ..
-DCMAKE_PREFIX_PATH=/home/loaden/qpSOFT/Projects/BuildQt5-m64/qtbase
-DCMAKE_TOOLCHAIN_FILE=~/.mingw64.cmake
-- The C compiler identification is GNU 4.7.1
-- The CXX compiler identification is GNU 4.7.1
-- Check for working C compiler: /opt/mingw64/bin/x86_64-w64-mingw32-gcc
-- Check for working C compiler: /opt/mingw64/bin/x86_64-w64-mingw32-gcc
-- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /opt/mingw64/bin/x86_64-w64-mingw32-g++
-- Check for working CXX compiler: /opt/mingw64/bin/x86_64-w64-mingw32-g++
-- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/loaden/qpSOFT/Projects/demo/m64
loaden@qpsoft:~/qpSOFT/Projects/demo/m64$ make
Scanning dependencies of target helloworld_automoc
[ 33%] Automoc for target helloworld
[ 33%] Built target helloworld_automoc
Scanning dependencies of target helloworld
[ 66%] Building CXX object CMakeFiles/helloworld.dir/main.cpp.obj
[100%] Building CXX object
CMakeFiles/helloworld.dir/helloworld_automoc.cpp.obj
Linking CXX executable helloworld.exe
[100%] Built target helloworld
When I try another demo, it's failed, and I can't find the reason.
CMakeLists.txt
cmake_minimum_required(VERSION 2.8.9 FATAL_ERROR)
project(testproject)
# Find includes in corresponding build directories
set(CMAKE_INCLUDE_CURRENT_DIR ON)
# Instruct CMake to run moc automatically when needed
set(CMAKE_AUTOMOC ON)
# Find the QtWidgets library
find_package(Qt5Widgets REQUIRED)
# Tell CMake to create the helloworld executable
add_executable(helloworld
main.cpp
mainwindow.cpp
mainwindow.ui
)
# Use the Widgets module from Qt 5
qt5_use_modules(helloworld Widgets)
# Support UI files
qt5_wrap_ui(ui_mainwindow.h mainwindow.ui)
I can sure this project can be build for Linux target.
It's just failed for cross build.
loaden@qpsoft:~/qpSOFT/Projects/qtdemo/m64$ cmake ..
-DCMAKE_PREFIX_PATH=/home/loaden/qpSOFT/Projects/BuildQt5-m64/qtbase
-DCMAKE_TOOLCHAIN_FILE=~/.mingw64.cmake
-- The C compiler identification is GNU 4.7.1
-- The CXX compiler identification is GNU 4.7.1
-- Check for working C compiler: /opt/mingw64/bin/x86_64-w64-mingw32-gcc
-- Check for working C compiler: /opt/mingw64/bin/x86_64-w64-mingw32-gcc
-- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /opt/mingw64/bin/x86_64-w64-mingw32-g++
-- Check for working CXX compiler: /opt/mingw64/bin/x86_64-w64-mingw32-g++
-- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to:
/home/loaden/qpSOFT/Projects/qtdemo/m64
loaden@qpsoft:~/qpSOFT/Projects/qtdemo/m64$ make
Scanning dependencies of target helloworld_automoc
[ 20%] Automoc for target helloworld
Generating moc_mainwindow.cpp
No such file or directory
AUTOMOC: error: process for
/home/loaden/qpSOFT/Projects/qtdemo/m64/moc_mainwindow.cpp failed:
No such file or directory
moc failed...
make[2]: *** [CMakeFiles/helloworld_automoc] Error 1
make[1]: *** [CMakeFiles/helloworld_automoc.dir/all] Error 2
make: *** [all] Error 2
--
Best Regards
Yuchen
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
It's can be fixed just replace the mingw32-make.exe. And it's the best choice to separate package for 32bit vs 64bit really. -m32 and -m64 will possible can't works well on Windows. 2012/8/30 marius.storm-ol...@nokia.com Rubens release is currently broken, and there shouldn't be a need for a separate package for 32bit vs 64bit really. -- Best Regards Yuchen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CMake for Qt5: Does exist set(CMAKE_AUTOUIC ON) support? or plan?
On Thursday, August 30, 2012 23:24:51 Loaden wrote: set(CMAKE_AUTOMOC ON) is great. But for now I have to use qt5_wrap_ui macros. e.g. snip Any help? Thanks! I don't think there is any plan for an auto-uic feature. It might be possible, but I've not thought too much about it. I guess Alex (who integrated the AUTOMOC stuff into cmake) didn't either because KDE has to use a different macro for uic stuff anyway. It's not a bad idea to have an auto-uic feature (I think), but I don't think it's as obvious how it should work as it is with moc. 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 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
[Development] FYI: Better usage of the global qdocconf in qtbase
(Since there are so many people working on the documentation now I thought it'd be okay to use the list). I created https://codereview.qt-project.org/#change,33974 to make the global qdocconf in qtbase more useful (and minimize duplication). This change assumes that -installdir will always be specified when building modular documentation (e.g. use make docs). I think we should also put all of the qdoc defines in one central file, but that'll come later. Probably we will need an *-online-templates soon, since I am working on a simple search system for the Qt5 documentation (non-DevNet, so only the snapshot and when you build the docs yourself). Casper P.S. I would like to thank everybody for helping out with the docs! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
On quinta-feira, 30 de agosto de 2012 16.59.13, Laszlo Papp wrote: I am wondering, if it was possible to get .bz2 tarballs as well? This is a preferred format at times for packagings. We were doing them until the day before yesterday. Discussing yesterday, we decided that it wasn't worth the disk space to have all three of .tar.xz, .tar.bz2 and .tar.gz. On my suggestion, we dropped .tar.bz2. We're keeping .tar.gz to ensure maximum compatibility and .tar.xz because it's the smaller of the three. I'd rather not bring back .tar.bz2. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden 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] Qt 5 beta
On Thu, Aug 30, 2012 at 5:08 PM, Thiago Macieira thiago.macie...@intel.comwrote: On quinta-feira, 30 de agosto de 2012 16.59.13, Laszlo Papp wrote: I am wondering, if it was possible to get .bz2 tarballs as well? This is a preferred format at times for packagings. We were doing them until the day before yesterday. Discussing yesterday, we decided that it wasn't worth the disk space to have all three of .tar.xz, .tar.bz2 and .tar.gz. On my suggestion, we dropped .tar.bz2. We're keeping .tar.gz to ensure maximum compatibility and .tar.xz because it's the smaller of the three. I'd rather not bring back .tar.bz2. It is ok, if the space is (can be) a bottleneck. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CMake for Qt5: Cross Compilation for Windows using MinGW-w64
On Thursday, August 30, 2012 23:53:27 Loaden wrote: snip loaden@qpsoft:~/qpSOFT/Projects/qtdemo/m64$ make Scanning dependencies of target helloworld_automoc [ 20%] Automoc for target helloworld Generating moc_mainwindow.cpp No such file or directory AUTOMOC: error: process for /home/loaden/qpSOFT/Projects/qtdemo/m64/moc_mainwindow.cpp failed: No such file or directory moc failed... make[2]: *** [CMakeFiles/helloworld_automoc] Error 1 make[1]: *** [CMakeFiles/helloworld_automoc.dir/all] Error 2 make: *** [all] Error 2 Update your qtbase checkout to make sure 5408225286dfdd4cd957c129db0873cbbab05bc0 (cmake: use .exe suffix only on Windows) is in it. If you use make VERBOSE=1 you'll see that make is attempting to run moc.exe, which does not exist. 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 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] CMake for Qt5: Cross Compilation for Windows using MinGW-w64
It fixed the problem. Thanks! 2012/8/31 Stephen Kelly stephen.ke...@kdab.com 5408225286dfdd4cd957c129db0873cbbab05bc0 -- Best Regards Yuchen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Maintainership for some APIs
On 14/08/2012, at 6:12 PM, lars.kn...@nokia.com lars.kn...@nokia.com wrote: On Aug 14, 2012, at 7:35 AM, ext alex.blas...@nokia.com alex.blas...@nokia.com wrote: -Original Message- From: development-bounces+alex.blasche=nokia@qt-project.org Qt SystemInfo and Qt Sensors could find a new owner in Lorn Potter and Aaron Mccarthy expressed interest in Qt NFC. The other API's remain open. If nobody violently disagrees then I would update the wiki of maintainers accordingly to indicate vacant spots or new maintainers. In hindsight the above statement could be read the wrong way. What I wanted to express is a nomination of the maintainer role for Aaron (NFC) and Lorn (SystemInfo Sensors). Both have contributed a substantial amount to those libraries already and although we (Brisbane folks) may not have the time to contribute on a fulltime basis there is a substantial interest among individuals. Lorn and Aaron are such developers and I am glad for their participation and energy. Both Aaron and Lorn have my full support. It's great to see them step up! *bump* Where are we on this maintainership issue? 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
[Development] Brisbane's last day
Hi Qtland, Brisbane's last day was effectively yesterday, as all our machines got wiped last night. Happy to say some of us are able and willing continue our roles in the qt-project. Thanks for those people (Thiago!) that put the open governance into place. I would say most of the talented engineers in Brisbane are still looking for jobs. (hint, hint, hint) Declarative, location, multimedia, systems/sensors and QA were all developed in Brisbane. It's been a great run for me at Trolltech and then Nokia. I first started with Trolltech in 2003 as Qtopia Community Liaison, and finished with Nokia as Senior Software Engineer developing QSensorGestures and its recognizers. Going through all the accumulated junk in the office, all the Trolltech prototypes, phones and whatnot, and looking back, I am very proud to say I was a part of Trolltech and Qtopia development, and also of Nokia, the most awesome N9 and Symbian^3. Our work back then was on quite a few more varied devices than it was the last few years. With only a handful of engineers, we released the first open source phone - the Greenphone (minus a binary blob or two)! I hope and trust the spirit of Trolltech's values will continue to live within the qt-project and the companies that use it. As the official last day we have possession of our key cards, in true Aussie style, most of our last tasks are having a BBQ, followed by a pub crawl downtown Brisbane. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Brisbane's last day
Brisbane folks: I would say most of the talented engineers in Brisbane are still looking for jobs. (hint, hint, hint) How's your Finnish / Suomi? Is Digia hiring? Jolla certainly still is! Atlant -Original Message- From: development-bounces+aschmidt=dekaresearch@qt-project.org [mailto:development-bounces+aschmidt=dekaresearch@qt-project.org] On Behalf Of Lorn Potter Sent: Thursday, August 30, 2012 2:20 PM To: development@qt-project.org Subject: [Development] Brisbane's last day Hi Qtland, Brisbane's last day was effectively yesterday, as all our machines got wiped last night. Happy to say some of us are able and willing continue our roles in the qt-project. Thanks for those people (Thiago!) that put the open governance into place. I would say most of the talented engineers in Brisbane are still looking for jobs. (hint, hint, hint) Declarative, location, multimedia, systems/sensors and QA were all developed in Brisbane. It's been a great run for me at Trolltech and then Nokia. I first started with Trolltech in 2003 as Qtopia Community Liaison, and finished with Nokia as Senior Software Engineer developing QSensorGestures and its recognizers. Going through all the accumulated junk in the office, all the Trolltech prototypes, phones and whatnot, and looking back, I am very proud to say I was a part of Trolltech and Qtopia development, and also of Nokia, the most awesome N9 and Symbian^3. Our work back then was on quite a few more varied devices than it was the last few years. With only a handful of engineers, we released the first open source phone - the Greenphone (minus a binary blob or two)! I hope and trust the spirit of Trolltech's values will continue to live within the qt-project and the companies that use it. As the official last day we have possession of our key cards, in true Aussie style, most of our last tasks are having a BBQ, followed by a pub crawl downtown Brisbane. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Click https://www.mailcontrol.com/sr/Cagy1jzruN7TndxI!oX7Ulvwl1GqFAPrLLSYFmmd+mk82svrRUdGn6ZvoXQaDOjK2kF3Qis0KhRLRkMuvIdUTQ== to report this email as spam. This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
On 8/30/12 6:16 PM, ext Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 30 de agosto de 2012 17.25.24, Pau Garcia i Quiles wrote: There are more differences than that. There are differences in features, such as threading support, large-file support, etc. Mingw-w64 is usually ahead of any other in terms of features. My suggestion on how to proceed is to choose one that offers the following or most of the following: - most recent GCC (4.7 preferably, 4.6 if not) - *working* GDB and tested with Creator, with Python support - large file support, threading - zero-overhead exceptions (no SJLJ exceptions) - standard win32 headers, if possible using the Platform SDK headers - large set of win32 import libraries - 32 and 64-bit in one package - make with -j support - if this exists: can link to .dll directly, instead of import libs We should choose one version to be the reference platform and work on making it Tier 1. We shouldn't have two versions, that duplicates work. Very ambitious! :) Linking directly with DLLs is only possible for MinGW if the DLLs were created by MinGW, for all other DLLs you need to create an import library (.lib) with the 'dlltool' provided with any MinGW installation (perhaps as mingw32-dlltool or similar). Always using Import Libraries ensures that the link process is always the same, no matter if the libraries are static or dynamic. If you want to link directly with DLLs you would also need changes in qmake, most likely, which I think you'd want to avoid. Most of the GNU makes released *do* support -j, but they often need sh.exe in the PATH to enable the functionality for some reason. To satisfy all the requirements above, we might need to compile MinGW ourselves. While not impossible, I suggest we actively participate with the MinGW community instead to make sure that this is what is released naturally from its community. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
- Original Message - From: Thiago Macieira thiago.macie...@intel.com To: development@qt-project.org Sent: Thursday, August 30, 2012 1:07 PM Subject: Re: [Development] Qt 5 beta On quinta-feira, 30 de agosto de 2012 17.30.58, Laszlo Papp wrote: I'd rather not bring back .tar.bz2. It is ok, if the space is (can be) a bottleneck. It's another 350 MB. We can offer it, but is there really the need? Can't you use .tar.xz instead? tar.bz2 is pretty common, along with tar.gz. tar.xy, OTOH, is quite rare. Googling tar.bz2 yields good results what to do with such a file. Googling tar.xy yields nothing useful about what compression engine is used even used; Googling compressed file extensions yielded Wikipedia's list of archive formats which finally produced some useful info - that it's an LZMA2 compression. While I understand that tar.xy may be smaller it's use general use seems to be limited so unless there is a supported platform/target that only uses tar.xy, I'd suggest dropping it and keeping tar.bz2 instead. Given a choice between a bzip and gzip, I'd personally choose bzips. If space is a concern, then zip and tar.gz are probably sufficient for distribution. $0.02 Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
tar.bz2 is pretty common, along with tar.gz. tar.xy, OTOH, is quite rare. Googling tar.bz2 yields good results what to do with such a file. Googling tar.xy yields nothing useful about what compression engine is used even used; Googling compressed file extensions yielded Wikipedia's list of archive formats which finally produced some useful info - that it's an LZMA2 compression. While I understand that tar.xy may be smaller it's use general use seems to be limited so unless there is a supported platform/target that only uses tar.xy, I'd suggest dropping it and keeping tar.bz2 instead. +1. Selecting xz, but not bz2 is a suboptimal decision in my opinion. I would personally even go further with this, if there is no space contraints for about 350 MB for such releases like this: it would be nice to distribute all those three formats because each of them may be used by several distributions and individuals. bz2 may be used by Ubuntu, Debian, Harmattan, Fremantle, debian based raspberry pi, ubuntu arm based beagleboard and so forth. They can also use tar.gz as far as I know, but at least for Harmattan we packagers for sure prefer the bz2 variant. xz may be used for Archlinux, Chakra, Frugalware, and so forth. I do not personally see (apart from space limitations) why only certain distribution formats would be dropped from the aforementioned, but others not. It would not be too fair in my opinion. Even if any of those is dropped, I would not drop the debian based preference because of the common usage of the bz2 format here and there. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
On Thursday 30 August 2012 11:48:38 BRM wrote: tar.bz2 is pretty common, along with tar.gz. tar.xy, OTOH, is quite rare. Googling tar.bz2 yields good results what to do with such a file. Googling tar.xy yields nothing useful about what compression engine is used even used; Googling compressed file extensions yielded Wikipedia's list of archive formats which finally produced some useful info - that it's an LZMA2 compression. While I understand that tar.xy may be smaller it's use general use seems to be limited so unless there is a supported platform/target that only uses tar.xy, I'd suggest dropping it and keeping tar.bz2 instead. Given a choice between a bzip and gzip, I'd personally choose bzips. If space is a concern, then zip and tar.gz are probably sufficient for distribution. $0.02 Ben I'm not sure wether it's just a typo, but you consistently write .xy so I'm going to assume not. Also, first and third tar.xz results in google for me are: http://ubuntuforums.org/showthread.php?t=1116012 http://en.wikipedia.org/wiki/Xz Not being a packager I don't know, but I have a hard time imagining it's harder to change your packaging scripts from Qt4 to Qt5 than from tar.bz2 to tar.xz. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
Not being a packager I don't know, but I have a hard time imagining it's harder to change your packaging scripts from Qt4 to Qt5 than from tar.bz2 to tar.xz. 1) This could be said vice versa, so not fair to say. 2) We have had bz2 previously (as well) and we were able to package with bz2, so this could potentially be changing for people from what was working. 3) Why another change in the first place, if there are no space limitations? 4) Just one random example of those: when I mentioned this to one of friends today he was asking what xz exactly. That person was aware of the other formats. He has also made some packagings already for Harmattan, so not quite a newcomer. I know, this could happen vice versa, so not fair to say... That is why I think, it is ok to keep both, or the more common bz2 format, if we are really short with space. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 beta
On quinta-feira, 30 de agosto de 2012 21.10.16, Laszlo Papp wrote: Not being a packager I don't know, but I have a hard time imagining it's harder to change your packaging scripts from Qt4 to Qt5 than from tar.bz2 to tar.xz. 1) This could be said vice versa, so not fair to say. 2) We have had bz2 previously (as well) and we were able to package with bz2, so this could potentially be changing for people from what was working. 3) Why another change in the first place, if there are no space limitations? Because LZMA produces smaller files. I'd like to increase adoption of it. So let me put it this way: upgrade or go back to gzip. 4) Just one random example of those: when I mentioned this to one of friends today he was asking what xz exactly. That person was aware of the other formats. He has also made some packagings already for Harmattan, so not quite a newcomer. I know, this could happen vice versa, so not fair to say... That is why I think, it is ok to keep both, or the more common bz2 format, if we are really short with space. I disagree. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden 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] Qt 5 beta
From: Jonas M. Gastal jgas...@profusion.mobi To: development@qt-project.org; BRM bm_witn...@yahoo.com Sent: Thursday, August 30, 2012 4:02 PM Subject: Re: [Development] Qt 5 beta On Thursday 30 August 2012 11:48:38 BRM wrote: tar.bz2 is pretty common, along with tar.gz. tar.xy, OTOH, is quite rare. Googling tar.bz2 yields good results what to do with such a file. Googling tar.xy yields nothing useful about what compression engine is used even used; Googling compressed file extensions yielded Wikipedia's list of archive formats which finally produced some useful info - that it's an LZMA2 compression. While I understand that tar.xy may be smaller it's use general use seems to be limited so unless there is a supported platform/target that only uses tar.xy, I'd suggest dropping it and keeping tar.bz2 instead. Given a choice between a bzip and gzip, I'd personally choose bzips. If space is a concern, then zip and tar.gz are probably sufficient for distribution. $0.02 Ben I'm not sure wether it's just a typo, but you consistently write .xy so I'm going to assume not. Also, first and third tar.xz results in google for me are: http://ubuntuforums.org/showthread.php?t=1116012 http://en.wikipedia.org/wiki/Xz Not being a packager I don't know, but I have a hard time imagining it's harder to change your packaging scripts from Qt4 to Qt5 than from tar.bz2 to tar.xz. A typo and misreading on my part. And yes, correcting that does yield more pertinent information. I'd still argue it is good to keep tar.bz2. Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5.0 Beta Performance
I download the latest beta version of Qt 5.0 onto my Linux box (Kubuntu 12.04) . For a beta it looks real good, but one thing I found concerning was the performance. I mean even running the demo samegame take over 98% of my cpu. Being that it is only the first beta release I am sure there is plenty of room for optimization, but 98% of my I5-2500 cpu seems a little excessive. I did the default configure and build so maybe it was built without any optimization. Any thoughts on this ? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
Currently, official MinGW project provides GCC 4.7, but it uses SJLJ exception mode when TDM/MinGW-w64/MinGW-build projects use Dwarf2 exception mode which is known as zero-overhead exception. All those MinGW and forks contain mingw32-make.exe util which does have -j option, but in fact this option doesn't make the real parallel build. Maybe sh.exe is needed, but this shell util will pass the incompatible path string so that the build process will be interrupted. TDM/MinGW-builds projects provide -m32/-m64 option to generate 32bit/64bit binaries using the same package, I don't know if qmake supports it. On Fri, Aug 31, 2012 at 2:30 AM, marius.storm-ol...@nokia.com wrote: On 8/30/12 6:16 PM, ext Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 30 de agosto de 2012 17.25.24, Pau Garcia i Quiles wrote: There are more differences than that. There are differences in features, such as threading support, large-file support, etc. Mingw-w64 is usually ahead of any other in terms of features. My suggestion on how to proceed is to choose one that offers the following or most of the following: - most recent GCC (4.7 preferably, 4.6 if not) - *working* GDB and tested with Creator, with Python support - large file support, threading - zero-overhead exceptions (no SJLJ exceptions) - standard win32 headers, if possible using the Platform SDK headers - large set of win32 import libraries - 32 and 64-bit in one package - make with -j support - if this exists: can link to .dll directly, instead of import libs We should choose one version to be the reference platform and work on making it Tier 1. We shouldn't have two versions, that duplicates work. Very ambitious! :) Linking directly with DLLs is only possible for MinGW if the DLLs were created by MinGW, for all other DLLs you need to create an import library (.lib) with the 'dlltool' provided with any MinGW installation (perhaps as mingw32-dlltool or similar). Always using Import Libraries ensures that the link process is always the same, no matter if the libraries are static or dynamic. If you want to link directly with DLLs you would also need changes in qmake, most likely, which I think you'd want to avoid. Most of the GNU makes released *do* support -j, but they often need sh.exe in the PATH to enable the functionality for some reason. To satisfy all the requirements above, we might need to compile MinGW ourselves. While not impossible, I suggest we actively participate with the MinGW community instead to make sure that this is what is released naturally from its community. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Regards, Fan Yang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Idea for automatic widget layout
Hello, I had an idea for automating widget layout in a framework like Clutter, Gtk+, or Qt. Imagine you have a row of widgets that are competing for horizontal space. Instead of having the developer (who is using the framework) declare a custom size for each widget, you could instead have the widget designer declare a mathematical function that takes the widget's width and returns a value indicating how much utility [1] the widget gets from that width. Then, you can sum the utilities for all the widgets in the row, and then run an optimization algorithm [2] in order to figure out the allocation that maximizes this sum. This optimization could be performed at compile time to achieve a static layout, or dynamically at runtime whenever the window size changes or the widgets' contents change. As an example, let's say you have a widget displaying a table or spreadsheet populated with some data. Assume the widget has the ability to automatically add scrollbars if there is not enough room to display its contents. If there is not enough room to display all the columns in this table, then the user will still get some partial benefit from being able to see only a few of the columns in the table; they can scroll through the rest. The more columns, the better, however: this minimizes the amount of scrolling necessary. The user will *not* get much benefit, however, out of being able to see half of a column: if there is enough space to display, say, 3.5 columns, then the table might as well be big enough to display only 3 columns: the user won't be able to read anything in the extra half-column anyway. Hence, the utility curve for this widget will end up looking something like a step function (but will flatten for widths that are enough to display all the data). As another example, an image will have a utility curve that grows drastically initially, but slows down once the image is large enough for the user to discern its contents. The curve of the widget will depend on the widget's content, and may change as the program runs. Widgets may change their internal layout entirely at certain sizes (e.g. a widget may display text and an icon at larger sizes, but display only an icon at smaller sizes); in this situation, the utility curve will end up being a piecewise function. The application designer (who is distinct from the widget designer) may also be able to supply parameters to alter the utility curve; the most obvious example is a parameter that would scale the whole utility curve, making that widget bigger in the layout. If no good choice for a utility curve is immediately apparent, then a curve of the form k*ln(w) (where w is the input width and k is a scaling parameter) is a good default. If all the widgets in a row are assigned this curve, then it turns out that the optimal width of each widget is proportional to that widget's k parameter. I don't know how useful/practical this idea is, but I don't think I have the time to create an effective implementation all by myself. If some of the Clutter or Gtk+ folks are interested in implementing this idea in their framework, I'd love to help out, though (sorry Qt devs, but I'm a GNOME guy). - Kerrick [1] The units of the utility value are meaningless, but all the widgets within a library should have utility curves that are commensurate with each other, so that their default behavior is reasonable. [2] Optimization is well-studied; see https://en.wikipedia.org/wiki/Mathematical_optimization. However, the choice of algorithm with which to perform the optimization is crucial, especially if the optimization will be carried out at runtime. An appropriate algorithm should be very fast, but doesn't necessarily need to return the global maximum; instead, it should return a layout that's good enough. As time progresses and CPU power increases, increasingly sophisticated algorithms can be used for this purpose. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
