Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Tue, Apr 17, 2012 at 4:12 AM, Girish Ramakrishnan gir...@forwardbias.in wrote: 1. qtestlib ends up exposing qpa api and thus testcases might end up being binary incompatible - This should be fixed in AFAIK qtestlib doesn't promise binary compatibility (see e.g. http://qt.gitorious.org/qt/qtqa/commit/0a67286dcc3513880dbbb01a72596b1e08741fea/diffs) so I'm not sure if this actually needs fixing - but I'll leave that up to the folks working on testlib :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Tue, Apr 17, 2012 at 4:12 AM, Girish Ramakrishnan gir...@forwardbias.in wrote: 1. qtestlib ends up exposing qpa api and thus testcases might end up being binary incompatible - This should be fixed in AFAIK qtestlib doesn't promise binary compatibility (see e.g. http://qt.gitorious.org/qt/qtqa/commit/0a67286dcc3513880dbbb01a72596b1e08741fea/diffs) so I'm not sure if this actually needs fixing - but I'll leave that up to the folks working on testlib :) That's right, testlib isn't included in the BC promises (there's way too much code in testlib that gets inlined via macros and no use of Qt-style private classes), but should still maintain source-compatibility once 5.0.0 is out. That said, testlib shouldn't needlessly expose other private APIs, so it would be good to fix the issue with qpa properly. -- Jason McDonald QTestLib Maintainer ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving checksdk.exe to qtbase repo
On Tuesday 17 April 2012 05:23:20 Anttila Janne wrote: Hi, I started building Qt5 for WinCE and WEC7, and found that checksdk is not currently build by configure and it has been moved to QtTools repo. Checksdk.exe is an utility to read WinCE environment from Visual Studio configuration file and it is used by setcepaths.bat. Setcepaths.bat is called by user after configuring Qt for WinCE and before executing make to apply correct environment for Qt building. In Qt4, checksdk is located in tools\checksdk folder, but it is bootstrapped correspondingly as other build time tools such as moc, i.e. checksdk.pro contains line include(../../src/tools/bootstrap/bootstrap.pri) So is it ok to move checksdk to qtbase repo and src\tools folder? Or do you have better ideas for building it? Yes. I suppose the team that did the modularisation did not realized the use of this application :-) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qHash / QHash changes
On Sunday 15 April 2012 20:38:22 Thiago Macieira wrote: On segunda-feira, 16 de abril de 2012 00.08.43, Olivier Goffart wrote: On Saturday 14 April 2012 20:06:53 Giuseppe D'Angelo wrote: So, after *too many* commits[1] -- QHash randomization was merged a few hours ago! https://qt.gitorious.org/qt/qtbase/commit/c01eaa438200edc9a3bbcd8ae1e8de d0 58 bea268 Thanks to all of the guys involved for the ideas, feedback, reviewing the patches... and staging them :-) Nice work! I'm just not really happy with the fact that you removed the optimisation for int to avoid storing both the hash and the key. It was stored as the same field because hash and key were the same. if you salt the hash, it's no longer the same. Therefore, they can't share a field. By not salting the hash for integer. Or only doing it before applying the % ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote: As per the previous discuss, I renamed all the _qpa.h to _p.h with a couple of helper scripts I just added the following -1 comment on gerrit: I do not agree with this change. We have made a difference between public API and plugin API, and this is different from private implementation detail. The rest of the Lighthouse team are also skeptical. The main issue, as far as I can see, is documentation. This can be solved much in a much simpler way by using the \internal tag, as discussed earlier. There should also be a warning in the _qpa.h files, but it shouldn't be the don't even think of using this file warning from the _p.h file; these files are there for platform plugin authors to use. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving checksdk.exe to qtbase repo
On Tue, Apr 17, 2012 at 11:15:17AM +0200, ext Andreas Holzammer wrote: Am 17.04.2012 10:32, schrieb Oswald Buddenhagen: integrate it into qmake, so it is able to produce self-contained makefiles which don't need messing with the environment. And where should the mapping between sdk and mkspec go to? Or does the mkspec has then the sdk name in it? i don't know really, i haven't dealt with the wince specs much. one option is to have one spec per target config, which seems to be the case already (to some degree?). you only need to add some variable to the specs which would allow the dispatcher code in qmake to choose the right build config. this could also be used to preset the right config in the vcproj solution files. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Browsing the Qt Playground project repositories online
FTR: No mentionings, but Ossi has already fixed this issue. :-) Thanks for that! Best Regards, Laszlo Papp On Sun, Apr 8, 2012 at 1:12 PM, Laszlo Papp lp...@kde.org wrote: Hi, It would be nice to have an option for checking out Qt Playground projects from the web browsers. As far as I see, the only way currently to check out the source code is if I clone the desired Qt Playground repository. I guess those repositories are also supposed to be mirrored on gitorious. There are apparently some bugs then because I am not able to find the following Playground projects after searching: QtSerialPort: http://gitorious.org/search?q=QtSerialPort - No relevant results (just the old repository before the migration to Qt5). QtAudio3D: http://gitorious.org/search?q=QtAudio3D - No results. We have briefly discussed the topic in question with Marius on IRC, and there might be some issues with the mirroring code. Perhaps because there is a Playground project on gitorious [1] ? One idea might be that to introduce a QtPlayground mapping in there, or at least having a better mapping with the Playground. There might also be other approaches as well. At any rate, it would be nice to have this functionality fixed. Thank you in advance! :-) Best Regards, Laszlo Papp [1] http://gitorious.org/playground ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving checksdk.exe to qtbase repo
-Original Message- From: development-bounces+janne.anttila=digia@qt-project.org [mailto:development-bounces+janne.anttila=digia@qt-project.org] On Behalf Of Oswald Buddenhagen Sent: 17. huhtikuuta 2012 12:44 To: development@qt-project.org Subject: Re: [Development] Moving checksdk.exe to qtbase repo On Tue, Apr 17, 2012 at 11:15:17AM +0200, ext Andreas Holzammer wrote: Am 17.04.2012 10:32, schrieb Oswald Buddenhagen: integrate it into qmake, so it is able to produce self-contained makefiles which don't need messing with the environment. And where should the mapping between sdk and mkspec go to? Or does the mkspec has then the sdk name in it? i don't know really, i haven't dealt with the wince specs much. one option is to have one spec per target config, which seems to be the case already (to some degree?). you only need to add some variable to the specs which would allow the dispatcher code in qmake to choose the right build config. this could also be used to preset the right config in the vcproj solution files. I wasn't aware of qmake ability to produce self-contained makefiles, so I will investigate approach suggested by Ossi. What comes to mappings between mkspecs and sdks in setcepaths.bat, I also don't like it and my idea was to replace it with something like this (from my Qt4 development branch): http://pastebin.com/DZCgJJbW. WinCE mkspecs already have CE_SDK which can be used to query environment related settings with the help of checksdk.exe. -- Janne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Request for a new playground project: Desktop Components
Desktop Compoents are not going to be a part of the Qt 5.0 release, but we'd still like to get it up to speed and open up for contributions through gerrit. Task: https://bugreports.qt-project.org/browse/QTQAINFRA-501 Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qHash / QHash changes
On 17 April 2012 08:59, Olivier Goffart oliv...@woboq.com wrote: By not salting the hash for integer. Or only doing it before applying the % Or specialize some QHash / QHashNode member for int key and re-xoring with the seed? But I can't say I'm familiar with that code and will have no time to do that asap -- would you accept a patch to reenable that in a couple of weeks if nobody steps up? Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt addons in gerrit - separate namespace or not?
Simple question, do we want the qt/ namespace to be for essentials only, or also for addons. e.g. should the path to an addon be: ssh://codereview.qt-project.org:29418/qt/qtftp or ssh://codereview.qt-project.org:29418/qtaddon/qtftp There are currently addons in qt/ and qt-labs/ but these were created early on before the playground/ namespace was created for research projects. -- Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Fwd: Re: [Interest] QtArg
Nice report. Most are expected changes. The one in QChar is a silent breakage, but documented in the changelog (in fact, it's the first one now): * drop a bogus QChar::NoCategory enum value; the proper QChar::Other_NotAssigned value is returned for an unassigned codepoints now. -- Forwarded message -- Subject: Re: [Interest] QtArg Date: terça-feira, 17 de abril de 2012, 11.32.30 From: Nikos Chantziaras rea...@gmail.com To: inter...@qt-project.org On 11/04/12 19:44, Thiago Macieira wrote: On quarta-feira, 11 de abril de 2012 18.20.52, Nikos Chantziaras wrote: If you have started to look into this, let us know quickly which modifications you have to make. Some of the transition needs might be unintentional and we still have time to fix them. Mostly differences with identifiers, changes in enums and the like and the trivial #include changes. I haven't ported one of my apps yet that makes heavy use of QPainter and QPixmap and implements custom widgets. Have yet to start on that. If you have time to write up a report on what needed to be done, from trivial changes to complex ones, we'll greatly appreciate the input. The sooner you provide it, the more we can do to lessen that pain. I've now came around and built the apps for Qt 5. It was *very* painless. The changes required were trivial. This single commit made the app Qt5-ready: http://qtads.git.sourceforge.net/git/gitweb.cgi?p=qtads/qtads;a=commitdiff;hlb05ec9c95868c3866b2ba864c5c515d994ccdb ___ Interest mailing list inter...@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest - -- 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] Removing the \compat QDoc command
Hi, We have multiple commands to mark documentation content as outdated: \deprecated, \obsolete and \compat. \compat was used for Qt3 compatibility. There are only 12 occurrences of \compat under qt5.git in the documentation, but none of that documentation actually gets printed. So please change the used command to \obsolete, or remove the QDoc comment, because this will give new QDoc errors once \compat is taken out of qdoc. The 12 locations of \compat outside of qdoc/the qdoc manual are: qtbase/src/printsupport/kernel/qprinter.cpp:373 qtbase/src/sql/kernel/qsql.qdoc:43 qtbase/src/sql/kernel/qsql.qdoc:54 qtbase/src/widgets/dialogs/qcolordialog.cpp:2005 qtbase/src/widgets/dialogs/qcolordialog.cpp:2010 qtbase/src/widgets/kernel/qapplication.cpp:3952 qtbase/src/widgets/kernel/qapplication.cpp:4050 qtbase/src/widgets/kernel/qapplication.cpp:4056 qtbase/src/widgets/widgets/qmenubar.cpp:1911 qtbase/src/widgets/widgets/qslider.cpp:540 qtbase/src/widgets/widgets/qslider.cpp:547 qtbase/src/widgets/widgets/qtextedit.cpp:2496 Casper ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
Hi Paul, On Tue, Apr 17, 2012 at 1:34 AM, Paul Olav Tvete paul.tv...@nokia.com wrote: On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote: As per the previous discuss, I renamed all the _qpa.h to _p.h with a couple of helper scripts I just added the following -1 comment on gerrit: I do not agree with this change. We have made a difference between public API and plugin API, and this is different from private implementation detail. The rest of the Lighthouse team are also skeptical. The main issue, as far as I can see, is documentation. This can be solved much in a much simpler way by using the \internal tag, as discussed earlier. There should also be a warning in the _qpa.h files, but it shouldn't be the don't even think of using this file warning from the _p.h file; these files are there for platform plugin authors to use. I marked them all as internal, preliminary and ingroup qpa for qdoc with a718a99438aaca7d4cd4379726a8e131d3c4bf89. I also added the 'we mean it' header (the one which you don't want) in 5369f506867532b039c7b2300d8319ff925b1434. I can change that header depending on the outcome of this discussion :) The current problems are: 1. _qpa.h ends up the QtGui master file. This means code completion in qt-creator. Since we have handle(), this means users will use these functions without thinking about the impact. 2. _qpa.h is now a new convention that end users need to be aware of. qdoc also creates the forwarding header #include ClassName for these files. What is the QPA team's suggestion to solve the above problems? (Fix syncqt, add pragmas to tell creator to stop processing them and/or educate people about _qpa headers? Do you guys also want people to develop plugins using creator? Do you guys even think the current state of affairs is not acceptable?). Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
Hi Marius, On Tue, Apr 17, 2012 at 4:03 AM, marius.storm-ol...@nokia.com wrote: On 17/04/2012 03:34, ext Paul Olav Tvete wrote: On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote: As per the previous discuss, I renamed all the _qpa.h to _p.h with a couple of helper scripts I just added the following -1 comment on gerrit: I do not agree with this change. We have made a difference between public API and plugin API, and this is different from private implementation detail. The rest of the Lighthouse team are also skeptical. The main issue, as far as I can see, is documentation. This can be solved much in a much simpler way by using the \internal tag, as discussed earlier. There should also be a warning in the _qpa.h files, but it shouldn't be the don't even think of using this file warning from the _p.h file; these files are there for platform plugin authors to use. Also remember that yes, we don't promise BC from 5.0.0, but at some point we would want the QPA api to stabilize at let it keep the same promise as the rest of Qt, don't we? At which point, we would have to rename the files again? This is how we have always done development in Qt. It starts out with _p.h and then becomes .h :) Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] api_changes merged back to master
Hi everybody, the merge of api_changes back into master for qtbase finally made it's way through the CI system. I'm currently in the process of merging declarative back and Kent is staging all the changes required to fix compilation of the other modules. From now on most changes should go to master. I'll keep api_changes around for another little while as there are still some changes in gerrit against it, but I would like to empty this queue now and then remove the api_changes branch soon. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
-Original Message- From: ext Girish Ramakrishnan [mailto:gir...@forwardbias.in] On Tue, Apr 17, 2012 at 4:03 AM, marius.storm-ol...@nokia.com wrote: On 17/04/2012 03:34, ext Paul Olav Tvete wrote: On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote: As per the previous discuss, I renamed all the _qpa.h to _p.h with a couple of helper scripts I just added the following -1 comment on gerrit: I do not agree with this change. We have made a difference between public API and plugin API, and this is different from private implementation detail. The rest of the Lighthouse team are also skeptical. The main issue, as far as I can see, is documentation. This can be solved much in a much simpler way by using the \internal tag, as discussed earlier. There should also be a warning in the _qpa.h files, but it shouldn't be the don't even think of using this file warning from the _p.h file; these files are there for platform plugin authors to use. Also remember that yes, we don't promise BC from 5.0.0, but at some point we would want the QPA api to stabilize at let it keep the same promise as the rest of Qt, don't we? At which point, we would have to rename the files again? This is how we have always done development in Qt. It starts out with _p.h and then becomes .h :) Well, that breaks SC for existing projects, which have been ok with the missing BC. So you want to improve by promising BC by breaking SC? -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Tuesday, April 17, 2012 15:05:49 marius.storm-ol...@nokia.com wrote: Well, that breaks SC for existing projects, which have been ok with the missing BC. So you want to improve by promising BC by breaking SC? _p also means SC is not maintained. 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] important: upcoming rename of _qpa.h to _p.h
Yes, it does. And for the case of QPA, we have said that we don't want to promise BC, but we haven't said that we will go around breaking SC for every patch release. (And we shouldn't, since SC breakage uses quite a bit of resources on all parties, so avoid them if you can.) Like some others, I would prefer it to remain in non-private headers, while mark the QPA API with non-BC promise. IMO, in Qt 5.1 we should be able to promise BC on the QPA APIs too. -- .marius From: development-bounces+marius.storm-olsen=nokia@qt-project.org [mailto:development-bounces+marius.storm-olsen=nokia@qt-project.org] On Behalf Of ext Stephen Kelly Sent: Tuesday, April 17, 2012 10:27 AM To: development@qt-project.org Subject: Re: [Development] important: upcoming rename of _qpa.h to _p.h On Tuesday, April 17, 2012 15:05:49 marius.storm-ol...@nokia.commailto:marius.storm-ol...@nokia.com wrote: Well, that breaks SC for existing projects, which have been ok with the missing BC. So you want to improve by promising BC by breaking SC? _p also means SC is not maintained. Thanks, -- Stephen Kelly stephen.ke...@kdab.commailto:stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.comhttp://www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] api changes
On terça-feira, 17 de abril de 2012 15.02.22, lars.kn...@nokia.com wrote: The access to screen() and display() may indicate a missing Qt API, which we may be able to add. If the X11 dependency was intentional, it can be ported to QPlatformNativeInterface, to obtain the XCB pointers. You can always do that. If we want more convenience I'm back at my proposal of adding a libQtX11Support add-on for X11 specific functionality. We will need such a lib anyway in order to provide classes like QX11EmbedXXX. Therefore, adding QX11Info to it is a no-brainer. Still, I'd like the application authors to recheck whether their X11 dependency was intentional. -- 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] api_changes merged back to master
yetch, and again, sorry Kent Were I but a beautiful woman, I would lend you a hug to give you the power to put this turkey down, once and for all. KO On Tue, Apr 17, 2012 at 8:36 PM, kent.han...@nokia.com wrote: Hi, The qtdeclarative merge (https://codereview.qt-project.org/#change,23550) still hasn't gone through; tests are crashing in the latest attempt. Modules that depend on qtdeclarative won't be able to merge any changes until the above merge is completed. Kent From: development-bounces+kent.hansen=nokia@qt-project.org [development-bounces+kent.hansen=nokia@qt-project.org] on behalf of Knoll Lars (Nokia-MP/Oslo) Sent: Tuesday, April 17, 2012 4:52 PM To: development@qt-project.org Subject: [Development] api_changes merged back to master Hi everybody, the merge of api_changes back into master for qtbase finally made it's way through the CI system. I'm currently in the process of merging declarative back and Kent is staging all the changes required to fix compilation of the other modules. From now on most changes should go to master. I'll keep api_changes around for another little while as there are still some changes in gerrit against it, but I would like to empty this queue now and then remove the api_changes branch soon. 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 -- --- °v° Donald Carr /(_)\ Vaguely Professional Penguin lover ^ ^ Cave canem, te necet lingendo Chasing my own tail; hate to see me leave, love to watch me go ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] api_changes merged back to master
On Tue, Apr 17, 2012 at 7:52 AM, lars.kn...@nokia.com wrote: Hi everybody, the merge of api_changes back into master for qtbase finally made it's way through the CI system. I'm currently in the process of merging declarative back and Kent is staging all the changes required to fix compilation of the other modules. From now on most changes should go to master. I'll keep api_changes around for another little while as there are still some changes in gerrit against it, but I would like to empty this queue now and then remove the api_changes branch soon. I have some api changes that I will be staging there, I should be done staging all of them this week. Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Found a serious issue about windows position (Qt5 master)
Why this bug is still Not Evaluated ? The bug still exist in current master, but better than before. 2012/3/21 Samuel Rødal samuel.ro...@nokia.com On 03/21/2012 02:31 AM, ext Loaden wrote: Hi, all, In currently, I can't visit bugreports in qt-project.org http://qt-project.org, so I don't know whether this bug has been reported. After build Qt5, please run linguist again and again, You will see the Windows Base Position auto moved to left. Same issue on QtCreator. Any comments are welcome! Thanks, I could reproduce and I've created this bug for it: https://bugreports.qt-project.org/browse/QTBUG-24905 -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Regards Loaden ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Found a serious issue about windows position (Qt5 master)
For now the position is auto move to top again and again when storing / restoring geometry. I hit this bug! 2012/4/18 Loaden loa...@gmail.com Why this bug is still Not Evaluated ? The bug still exist in current master, but better than before. 2012/3/21 Samuel Rødal samuel.ro...@nokia.com On 03/21/2012 02:31 AM, ext Loaden wrote: Hi, all, In currently, I can't visit bugreports in qt-project.org http://qt-project.org, so I don't know whether this bug has been reported. After build Qt5, please run linguist again and again, You will see the Windows Base Position auto moved to left. Same issue on QtCreator. Any comments are welcome! Thanks, I could reproduce and I've created this bug for it: https://bugreports.qt-project.org/browse/QTBUG-24905 -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Regards Loaden -- Regards Loaden ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
