Re: [Development] [Marketing] Qt Contributor Summit 2014 dates?
Em seg 17 fev 2014, às 07:18:36, Kojo Tero escreveu: Hi Thiago (and all), Yes, we have a date for the Contributor Summit. June 10-11, and the location this time will be Berlin. I'll post more information as soon as we have more details to share. Tero Kojo Qt Online Community Manager - Digia Thanks Tero I'll update my travel requests. P.S. I'll use this as a chance to say hi to all the people on these mailing lists too. I started three weeks back at Digia as an Online Community Manager. My short introduction letter on the forums: http://qt-project.org/forums/viewthread/37732/ I'll be around at least on the forums, IRC and these mailing lists, feel free to I saw the Twitter posts. Welcome to the team and let us know what we can do to help you out! -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qmake variable for iOS
To shed some more light,
QtCreator has extra logic on top of QMake to let it create different
shadowbuilds (and different XCode projects with different build settings) for
device and simulator. The config variables iphoneos and iphonesimulator is
set by QtCreator.
But QMake alone does not distinguish between device and simulator. Any XCode
project that you create with QMake (from QtCreator or from the terminal) will
always support both simulator and device. This is how XCode works. You switch
between device and simulator from the scheme menu inside XCode.
-Richard
Fra: development-bounces+richard.gustavsen=digia@qt-project.org
[development-bounces+richard.gustavsen=digia@qt-project.org] på vegne av
Shobana Suresh [ssur...@esri.com]
Sendt: 17. februar 2014 04:33
To: Mohamed Fawzi
Cc: development@qt-project.org
Emne: Re: [Development] Qmake variable for iOS
Hi Fawzi,
Thanks for the explanation.
You are right. Though the message is misleading, it appears to work.
I tried the below simple test and it worked as expected.
App1.pro:
ios {
iphonesimulator {
message(iphonesimulator)
DEFINES += iphonesimulator
}
iphoneos{
message(iphoneos)
DEFINES += iphoneos
}
}
Mainwindow.cpp
void MainWindow::on_pushButton_clicked()
{
QMessageBox msgBox;
#ifdef iphonesimulator
msgBox.setText(Simulator);
#elif defined (iphoneos)
msgBox.setText(Phone);
#endif
msgBox.exec();
}
Thanks
Shobana
From: Mohamed Fawzi fawzi.moha...@digia.commailto:fawzi.moha...@digia.com
Date: Sat, 15 Feb 2014 01:36:31 +1100
To: Shobana Suresh ssur...@esri.commailto:ssur...@esri.com
Cc: development@qt-project.orgmailto:development@qt-project.org
development@qt-project.orgmailto:development@qt-project.org
Subject: Re: [Development] Qmake variable for iOS
Hi,
qmake for ios is a bit strange, in the sense that it treats device and
simulator as two build versions.
This is like debug and release, setting it in CONFIG sets the default used in
Makefile, but it also still generates specific makefiles for each possible
combination (iphoneos debug/relase,...).
This is a bit unecessary, especially for how it is used in creator (shadow
build, always setting the default, and always building using the default
Makefile.
So message is misleading because it is called for each Makefile version.
Thill it should work, have you tried to see?
Fawzi
On 10 Feb 2014, at 01:30, Shobana Suresh
ssur...@esri.commailto:ssur...@esri.com wrote:
Hello All,
I am trying to find the qmake variable that could be used to differentiate
between the iPhone simulator and iPhone arm kits.
In my .pro file, I would like to use conditions like
1.
ios {
2.
CONFIG += c++11
3.
iphonesimulator {
4.
message(iphonesimulator)
5.
#Do Something
6.
}
7.
iphoneos{
8.
message(iphoneos)
9.
#Do Something
10.
}
11.
}
On running qmake with the iphonesimulator kit, it prints out
1.
Project MESSAGE: iphonesimulator
2.
Project MESSAGE: iphonesimulator
3.
Project MESSAGE: iphonesimulator
4.
Project MESSAGE: iphonesimulator
5.
Project MESSAGE: iphoneos
6.
Project MESSAGE: iphonesimulator
7.
Project MESSAGE: iphonesimulator
8.
Project MESSAGE: iphoneos
With iPhone device kit , it prints
1.
Project MESSAGE: iphoneos
2.
Project MESSAGE: iphoneos
3.
Project MESSAGE: iphoneos
4.
Project MESSAGE: iphonesimulator
5.
Project MESSAGE: iphoneos
6.
Project MESSAGE: iphoneos
7.
Project MESSAGE: iphonesimulator
8.
Project MESSAGE: iphoneos
I tried using the QT_ARCH variable, but message($$QT_ARCH) prints out “arm” for
both the kits.
What is the correct qmake variable to use to differentiate between iPhone
simulator and iPhone arm kits?
Regards
Shobana
___
Development mailing list
Development@qt-project.orgmailto:Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
__ Information from ESET NOD32 Antivirus, version of virus signature
database 9109 (20131128) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Marketing] Qt Contributor Summit 2014 dates?
Hi Thiago (and all), Yes, we have a date for the Contributor Summit. June 10-11, and the location this time will be Berlin. I'll post more information as soon as we have more details to share. Tero Kojo Qt Online Community Manager - Digia P.S. I'll use this as a chance to say hi to all the people on these mailing lists too. I started three weeks back at Digia as an Online Community Manager. My short introduction letter on the forums: http://qt-project.org/forums/viewthread/37732/ I'll be around at least on the forums, IRC and these mailing lists, feel free to -Original Message- From: marketing-bounces+tero.kojo=digia@qt-project.org [mailto:marketing-bounces+tero.kojo=digia@qt-project.org] On Behalf Of Thiago Macieira Sent: 15. helmikuuta 2014 3:04 To: development@qt-project.org; market...@qt-project.org Subject: [Marketing] Qt Contributor Summit 2014 dates? Hello Do we have potential dates for QCS this year? I'm being asked to fill in my Q2-2014 travel already... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Marketing mailing list market...@qt-project.org http://lists.qt-project.org/mailman/listinfo/marketing ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Marketing] Qt Contributor Summit 2014 dates?
On 17 Feb 2014, at 08:18, Kojo Tero tero.k...@digia.com wrote: Hi Thiago (and all), Yes, we have a date for the Contributor Summit. June 10-11, and the location this time will be Berlin. I'll post more information as soon as we have more details to share. Tero Kojo Qt Online Community Manager - Digia P.S. I'll use this as a chance to say hi to all the people on these mailing lists too. I started three weeks back at Digia as an Online Community Manager. My short introduction letter on the forums: http://qt-project.org/forums/viewthread/37732/ I'll be around at least on the forums, IRC and these mailing lists, feel free to Welcome to Qt! -Original Message- From: marketing-bounces+tero.kojo=digia@qt-project.org [mailto:marketing-bounces+tero.kojo=digia@qt-project.org] On Behalf Of Thiago Macieira Sent: 15. helmikuuta 2014 3:04 To: development@qt-project.org; market...@qt-project.org Subject: [Marketing] Qt Contributor Summit 2014 dates? Hello Do we have potential dates for QCS this year? I'm being asked to fill in my Q2-2014 travel already... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Marketing mailing list market...@qt-project.org http://lists.qt-project.org/mailman/listinfo/marketing ___ 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] Upcoming Gerrit Upgrade
On 17.02.2014 11:47, Giuseppe D'Angelo wrote: On 17 February 2014 10:11, Haataja Ismo ismo.haat...@digia.com wrote: one page review, are refactored for 2.7 but need few days to complete. Our of curiosity, are there any plans for upstreaming this particular feature? The fact that vanilla gerrit opens one browser tab per file (!!) when doing a review drives me crazy. Thanks, https://code.google.com/p/gerrit/issues/detail?id=938 more than 100 people are waiting for this feature upstream as well push it upstream and you will certainly get lots of help and reviews -- Sergio Ahumada sahum...@blackberry.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: rebranding QMF as QtMail
On Mon, Feb 17, 2014 at 1:41 AM, Sze Howe Koh szehowe@gmail.com wrote: The repository is currently comprised of two main libraries: QmfMessageServer and QmfClient. I would propose: QmfClient = QtMail QmfMessageServer = QtMessageServer Classes in QMF are already using the QMail* prefix. Any objections? +1 +1 for renaming, to avoid confusion (people might mistake them for QML Client or QML Message Server) To make the relationship between the 2 libraries more obvious, I'd give them similar names (e.g. QtEmailClient and QtEmailServer). I was kind of deliberately avoiding the Email name due to awkward capitalisation, I also think that Mail is sufficiently clear in an IT context. I wouldn't expect to find a Qt API for postal mail, after all. :-) You're right that it should probably be QtMailMessageServer, though. How big are the libraries? If they're small, what do you think of merging them into one library? I think there is value in keeping them split. The message server library is something that I personally think of as more of an implementation detail. It's used to implement plugins for the messageserver binary, not mail client tools. That's rather a limited goal/audience compared to the main library. BR, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Replacing ICU libraries with a minimal version
Hi all, A user has kindly shared a minimal ICU DLL, built for developers who don't intend to use ICU features: http://qt-project.org/forums/viewthread/38489/ Is this something we can host (or imitate) at the Qt Project? Perhaps it can be packaged in an extras directory, which developers can use in place of the full ICU DLLs when deploying an application. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Rules for including private headers
On Monday 17. February 2014 10.46.12 Ulf Hermann wrote: Sounds good to me. From what I read below, you just add the section about private headers, right? Yes. * If you need to include qt_x11_p.h, always include it as the last header file. This could go into the private headers section since it's private itself. I'd rather just delete it. What is so significant about qt_x11_p.h that it needs its own rule here? Please merge all cases into one: #include private/whatever_p.h The argument for case 1 (whatever_p.h) is that it's shorter and easier to see where the file is than with private/whatever_p.h. Both cases 1 and 2 (foo/bar/whatever_p.h) reduce the amount of indirection to look up the file and possibly speed up compile times that way. In case 3 (QtCore/private/whatever_p.h), as we are using private API of a different module, that should really be visible in the code, I think. I'm aware that those rules are pretty complex and the idea of one syntax to cover them all has its merits, but maybe we should take another look at the pros and cons. I'm in favor of keeping the rules simple, and therefore like the plain #include private/whatever_p.h If I really have doubts where a header is coming from, I just press F2 in creator, or better: Just hover with the mouse over the include and it tells me the absolute path in a tooltip. #include Module/private/whatever_p.h is IMO redundant. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: merge stable into release and dev into stable
On Monday 17. February 2014 07.16.12 Heikkinen Jani wrote: Hi all, It seems we cannot start merge from dev branch to stable at the moment because there is still some issues to be solved before that: 1. There seems to be compilation break in dev branch, see https://codereview.qt-project.org/#change,78283. That needs to be solved first This is solved now :) 2. There is still some merges ongoing from stable to dev branch *https://codereview.qt-project.org/#change,77965 *https://codereview.qt-project.org/#change,77972 *https://codereview.qt-project.org/#change,77977 *https://codereview.qt-project.org/#change,77258 3. Adding qtwebsockets as a submodule is still ongoing, see https://codereview.qt-project.org/#change,76844 For the sake of coordination, with regards to qtdeclarative: * I have a merge from stable to dev prepared that resolves the conflicts. After that you should be able to do the final merge yourself (should be a fast- forward if any) * However at the same time we have two big pending changes, currently targetted for dev, that we've been trying to integrate over the weekend: * QtQuickWidget * Support for GL switching (Dynamic GL patch) So we have three patches that need to go in: The merge, the QtQuickWidget changes and the dynamic GL changes. I suggest we try QtQuickWidget and Laszlo's GL changes first, and when those are in, then I'll try to stage the merge. If anyone else has other changes for qtdeclarative, please consider holding back and consider re-targetting to stable after the project branch or speak up :). Staging of unrelated changes will just slow down the process. Otherwise, let's also coordinate in #qt-labs. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Rules for including private headers
-Original Message- From: development-bounces+kai.koehne=digia@qt-project.org [mailto:development-bounces+kai.koehne=digia@qt-project.org] On Behalf Of Ulf Hermann Sent: Monday, February 17, 2014 10:46 AM To: development@qt-project.org Subject: Re: [Development] Rules for including private headers Sounds good to me. From what I read below, you just add the section about private headers, right? Yes. * If you need to include qt_x11_p.h, always include it as the last header file. This could go into the private headers section since it's private itself. I'd rather just delete it. What is so significant about qt_x11_p.h that it needs its own rule here? Please merge all cases into one: #include private/whatever_p.h The argument for case 1 (whatever_p.h) is that it's shorter and easier to see where the file is than with private/whatever_p.h. Both cases 1 and 2 (foo/bar/whatever_p.h) reduce the amount of indirection to look up the file and possibly speed up compile times that way. I did a quick reality check on this one: https://codereview.qt-project.org/#change,78318 changes all _p.h includes to a canonical private/xxx_p.h format, and I couldn't measure any difference when compiling on windows (where filesystem accesses are traditionally slow), both with and without patches applied. So I'd actually also support just using private/xxx_p.h everywhere. Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: merge stable into release and dev into stable
Mandag 17. februar 2014 13.01.05 skrev Simon Hausmann: On Monday 17. February 2014 07.16.12 Heikkinen Jani wrote: Hi all, It seems we cannot start merge from dev branch to stable at the moment because there is still some issues to be solved before that: 1. There seems to be compilation break in dev branch, see https://codereview.qt-project.org/#change,78283. That needs to be solved first This is solved now :) 2. There is still some merges ongoing from stable to dev branch *https://codereview.qt-project.org/#change,77965 *https://codereview.qt-project.org/#change,77972 *https://codereview.qt-project.org/#change,77977 *https://codereview.qt-project.org/#change,77258 3. Adding qtwebsockets as a submodule is still ongoing, see https://codereview.qt-project.org/#change,76844 For the sake of coordination, with regards to qtdeclarative: * I have a merge from stable to dev prepared that resolves the conflicts. After that you should be able to do the final merge yourself (should be a fast- forward if any) * However at the same time we have two big pending changes, currently targetted for dev, that we've been trying to integrate over the weekend: * QtQuickWidget * Support for GL switching (Dynamic GL patch) So we have three patches that need to go in: The merge, the QtQuickWidget changes and the dynamic GL changes. I suggest we try QtQuickWidget and Laszlo's GL changes first, and when those are in, then I'll try to stage the merge. Wouldn't it make more sense to re-target the stable branch for these? If anyone else has other changes for qtdeclarative, please consider holding back and consider re-targetting to stable after the project branch or speak up :). Staging of unrelated changes will just slow down the process. I don't think the release mailing list is read by everyone which is why I think this kind of don't stage in dev right now message generally doesn't work. Greetings, Frederik Otherwise, let's also coordinate in #qt-labs. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Plans for printing in 5.3 onwards
On Wednesday 12 Feb 2014 15:37:29 John Layt wrote: On Wednesday 12 Feb 2014 12:03:53 John Layt wrote: Sorry, needed to wait until the full stack of changes had been completed and integrated before pushing. The revised patches are up for review, I'm not sure we'll get it done in time, but it's worth a crack, otherwise I'll have to slog through the old code again fixing all the bugs I found for 5.3, only to replace the code again in 5.4. If people don't quite feel confident taking all the changes at once, one option is to take up Morten's earlier suggestion of not using the new platform plugin code just yet, i.e. * Merge the QPageLayout and QPageSize code and its use in QPrinter and QPrintEngine, as this is the code that fixes many bugs and removes the duplicated inconsistent code that is at the root of many issues. * Change the existing platform code to use QPageSize and QPageLayout internally * Merge the new QPA code, but don't use it as yet,and have the auto tests and manual tests available for people to test it more thoroughly. * Keep the patches switching to the new platform plugin code in reserve to either switch for 5.3 if testing proves the plugin is stable enough, or more likely to use in 5.4 if not. Hi, As noted on the Releasing list, I didn't get the OSX 10.7 blocker bug fixed in time, and using just the layout code without the plugin proved too much work to be stable in time, so *none* of this change set has made it for 5.3. Apologies and thanks to everyone who put so much effort into testing and reviewing the changes. The question is what to do now. I could look at porting some of the layout fixes to the old code as bug fixes for 5.3, but I'm not sure that's the best use of my time, plus most of the fixes are heavily dependent on the new QPageSize class to manage things without writing the same page size conversion code over again in 8 different classes. One option is to make the QPageSize and maybe QPageLayout classes private for 5.3 to allow them to be used in bug fixes, which could also allow the new QPA class in be included for wider testing via tests/manual/qprintdevice_dump before being used in 5.4, but that feels like cheating the freeze. Thoughts? Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: merge stable into release and dev into stable
On 17/02/14 13:01, Simon Hausmann simon.hausm...@digia.com wrote: On Monday 17. February 2014 07.16.12 Heikkinen Jani wrote: Hi all, It seems we cannot start merge from dev branch to stable at the moment because there is still some issues to be solved before that: 1. There seems to be compilation break in dev branch, see https://codereview.qt-project.org/#change,78283. That needs to be solved first This is solved now :) 2. There is still some merges ongoing from stable to dev branch *https://codereview.qt-project.org/#change,77965 *https://codereview.qt-project.org/#change,77972 *https://codereview.qt-project.org/#change,77977 *https://codereview.qt-project.org/#change,77258 3. Adding qtwebsockets as a submodule is still ongoing, see https://codereview.qt-project.org/#change,76844 For the sake of coordination, with regards to qtdeclarative: * I have a merge from stable to dev prepared that resolves the conflicts. After that you should be able to do the final merge yourself (should be a fast- forward if any) * However at the same time we have two big pending changes, currently targetted for dev, that we've been trying to integrate over the weekend: * QtQuickWidget * Support for GL switching (Dynamic GL patch) So we have three patches that need to go in: The merge, the QtQuickWidget changes and the dynamic GL changes. I suggest we try QtQuickWidget and Laszlo's GL changes first, and when those are in, then I'll try to stage the merge. If anyone else has other changes for qtdeclarative, please consider holding back and consider re-targetting to stable after the project branch or speak up :). Staging of unrelated changes will just slow down the process. Otherwise, let's also coordinate in #qt-labs. There are also the pending printer changes from John, that is pending. As we would like to do the branching to stable as soon as possible, So I¹m ok if GL switching, QQuickWidget and the printing patch series get pushed to stable after the merge as an exception to the feature freeze. But ideally we manage to get at least some of them in before. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Plans for printing in 5.3 onwards
On 17/02/14 13:47, John Layt jl...@kde.org wrote: On Wednesday 12 Feb 2014 15:37:29 John Layt wrote: On Wednesday 12 Feb 2014 12:03:53 John Layt wrote: Sorry, needed to wait until the full stack of changes had been completed and integrated before pushing. The revised patches are up for review, I'm not sure we'll get it done in time, but it's worth a crack, otherwise I'll have to slog through the old code again fixing all the bugs I found for 5.3, only to replace the code again in 5.4. If people don't quite feel confident taking all the changes at once, one option is to take up Morten's earlier suggestion of not using the new platform plugin code just yet, i.e. * Merge the QPageLayout and QPageSize code and its use in QPrinter and QPrintEngine, as this is the code that fixes many bugs and removes the duplicated inconsistent code that is at the root of many issues. * Change the existing platform code to use QPageSize and QPageLayout internally * Merge the new QPA code, but don't use it as yet,and have the auto tests and manual tests available for people to test it more thoroughly. * Keep the patches switching to the new platform plugin code in reserve to either switch for 5.3 if testing proves the plugin is stable enough, or more likely to use in 5.4 if not. Hi, As noted on the Releasing list, I didn't get the OSX 10.7 blocker bug fixed in time, and using just the layout code without the plugin proved too much work to be stable in time, so *none* of this change set has made it for 5.3. Apologies and thanks to everyone who put so much effort into testing and reviewing the changes. The question is what to do now. I could look at porting some of the layout fixes to the old code as bug fixes for 5.3, but I'm not sure that's the best use of my time, plus most of the fixes are heavily dependent on the new QPageSize class to manage things without writing the same page size conversion code over again in 8 different classes. One option is to make the QPageSize and maybe QPageLayout classes private for 5.3 to allow them to be used in bug fixes, which could also allow the new QPA class in be included for wider testing via tests/manual/qprintdevice_dump before being used in 5.4, but that feels like cheating the freeze. Thoughts? I¹ve been discussing a bit with Friedemann and Andy on IRC, and I¹m willing to give this change set an exception to the feature freeze. The reason is that I believe that this significantly improves our level of support in this area, and that the patch set is almost there. The API is pretty much ok now, so there won¹t be a lot more changes coming anymore. The main thing that¹s missing is bug fixing certain areas, and that¹s what the stabilisation period is there for. So please go ahead with your changes so that we can get them in within the next few days. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: merge stable into release and dev into stable
Hi all! I think we need to get merge done as soon as possible to make branches etc clear for everyone. That's why I propose to 1. Finalize those merges from stable to dev as soon as possible https://codereview.qt-project.org/#change,78341 https://codereview.qt-project.org/#change,78333 (Integrating) https://codereview.qt-project.org/#change,77965(Integrating) 2. do the merge from dev to stable tomorrow morning 3. re-target remaining changes related to GL switching, QQuickWidget and the printing patch series to the stable branch Br, Jani -Original Message- From: Knoll Lars Sent: 17. helmikuuta 2014 14:50 To: Hausmann Simon; development@qt-project.org Cc: Heikkinen Jani; releas...@qt-project.org; Paaso Matti Subject: Re: [Development] HEADS UP: merge stable into release and dev into stable On 17/02/14 13:01, Simon Hausmann simon.hausm...@digia.com wrote: On Monday 17. February 2014 07.16.12 Heikkinen Jani wrote: Hi all, It seems we cannot start merge from dev branch to stable at the moment because there is still some issues to be solved before that: 1. There seems to be compilation break in dev branch, see https://codereview.qt-project.org/#change,78283. That needs to be solved first This is solved now :) 2. There is still some merges ongoing from stable to dev branch *https://codereview.qt-project.org/#change,77965 *https://codereview.qt-project.org/#change,77972 *https://codereview.qt-project.org/#change,77977 *https://codereview.qt-project.org/#change,77258 3. Adding qtwebsockets as a submodule is still ongoing, see https://codereview.qt-project.org/#change,76844 For the sake of coordination, with regards to qtdeclarative: * I have a merge from stable to dev prepared that resolves the conflicts. After that you should be able to do the final merge yourself (should be a fast- forward if any) * However at the same time we have two big pending changes, currently targetted for dev, that we've been trying to integrate over the weekend: * QtQuickWidget * Support for GL switching (Dynamic GL patch) So we have three patches that need to go in: The merge, the QtQuickWidget changes and the dynamic GL changes. I suggest we try QtQuickWidget and Laszlo's GL changes first, and when those are in, then I'll try to stage the merge. If anyone else has other changes for qtdeclarative, please consider holding back and consider re-targetting to stable after the project branch or speak up :). Staging of unrelated changes will just slow down the process. Otherwise, let's also coordinate in #qt-labs. There are also the pending printer changes from John, that is pending. As we would like to do the branching to stable as soon as possible, So I¹m ok if GL switching, QQuickWidget and the printing patch series get pushed to stable after the merge as an exception to the feature freeze. But ideally we manage to get at least some of them in before. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Plans for printing in 5.3 onwards
John Layt sayeth: snip, Qt printing API changes As noted on the Releasing list, I didn't get the OSX 10.7 blocker bug fixed in time, and using just the layout code without the plugin proved too much work to be stable in time, so *none* of this change set has made it for 5.3. snip, Thoughts? Knoll Lars respondeth: I¹ve been discussing a bit with Friedemann and Andy on IRC, and I¹m willing to give this change set an exception to the feature freeze. The reason is that I believe that this significantly improves our level of support in this area, and that the patch set is almost there. The API is pretty much ok now, so there won¹t be a lot more changes coming anymore. The main thing that¹s missing is bug fixing certain areas, and that¹s what the stabilisation period is there for. So please go ahead with your changes so that we can get them in within the next few days. +1 --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Question about deferred delete handling in sendPostedEvents
Hi, I was looking at a problem regarding deferred deletes causing a crash inside nested loops and it was pointed out that in QCoreApplication::setPostedEvents() there is some code there that determines whether it is safe to delete the object or not. From my understanding it will only delete an object if the loop level that it was called from is greater than the current one. However it seems that if the loop level is 0 (i.e. main event loop I guess) and the current one is higher than 0 it deletes anyway, is this the correct intention? Does anyone know why this is safe if so? For reference the code is this bit specifically: const bool allowDeferredDelete = (loopLevel data-loopLevel || (!loopLevel data-loopLevel 0) || (event_type == QEvent::DeferredDelete loopLevel == data-loopLevel)); Where loopLevel is 0 but data-loopLevel is greater than 0. Regards, Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] libQt5WebKit5, libQt5WebKitWidgets5 and QtWebProcess doubt
On Sunday 16 February 2014 17:55:48 Thiago Macieira wrote: Em dom 16 fev 2014, às 21:25:29, Hausmann Simon escreveu: libQt5WebKit will execute QtWebProcess. It also links against widgets if it is available at build time, but that is an optional dependency. (it is used for style initialization) Unless something has changed there recently The point is that it links, so all three components must always be shipped together. They can't be split up. Bad luck then :) Thanks guys! -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ 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] Building Qt Webkit without MacroAssembler
On Sunday 16 February 2014 21:22:36 Hausmann Simon wrote: Yes, on architectures not supported by JIT/llint, the portable c-loop llint backend should be built/used. This is supposed to happen automatically (at build time). Which is not happening, so I guess I should fill a bug. Thanks a lot! -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ 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] look-behind assertions in syntax HL?
On 2014-02-16 12:02, Thiago Macieira wrote: Em dom 16 fev 2014, às 15:09:49, Giuseppe D'Angelo escreveu: I guess that for Kate's purposes a small wrapper class around QRegExp + QRegularExpression would suffice for supporting both syntaxes. For the future, we could instead think of adding wildcard and fixed-string pattern types to QRegularExpression. Fixed strings are supported already: QRegularExpression::escape. Does this know already to do a simply string compare to test the resulting regex? (And/or does compiling of the regex's already handle that case for any regex that is effectively a fixed string?) For me that has been the main reason to use a fixed-string pattern type. For wildcards, we should simply add another static that converts ? to . and * to .*. Do we want to support more interesting globbing things like []? Are these supported mainly because the pattern may be coming from user input, or because internally the match implementation can be more efficient? If the latter, I'm not sure it is worth even having a glob pattern type. If the former, then supporting as many shell-isms as possible is probably useful. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upcoming Gerrit Upgrade
Em seg 17 fev 2014, às 09:11:38, Haataja Ismo escreveu: Hi, As you might be aware, we have been working on Gerrit upgrade and we now have some news. Plan is to upgrade current 2.2.1 based version to 2.7 based. Our customized features, staging system for CI and one page review, are refactored for 2.7 but need few days to complete. We'd like to ask help for reviewing these changes and I'll get back to this later this week. Target date for production deployment is 7th March. Schedule is not frozen and it must be in sync with Qt5.3 release plan to keep that safe, not compromising the Qt release. Hello Ismo Thanks for the effort. I'm very happy that this is happening. I'm especially glad we're getting this: https://gerrit-documentation.googlecode.com/svn/Documentation/2.7/rest-api.html -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] look-behind assertions in syntax HL?
Em seg 17 fev 2014, às 11:06:52, Matthew Woehlke escreveu: On 2014-02-16 12:02, Thiago Macieira wrote: Em dom 16 fev 2014, às 15:09:49, Giuseppe D'Angelo escreveu: I guess that for Kate's purposes a small wrapper class around QRegExp + QRegularExpression would suffice for supporting both syntaxes. For the future, we could instead think of adding wildcard and fixed-string pattern types to QRegularExpression. Fixed strings are supported already: QRegularExpression::escape. Does this know already to do a simply string compare to test the resulting regex? (And/or does compiling of the regex's already handle that case for any regex that is effectively a fixed string?) For me that has been the main reason to use a fixed-string pattern type. We pass it to the PCRE engine. How it compiles and manages the pattern is its own business. For wildcards, we should simply add another static that converts ? to . and * to .*. Do we want to support more interesting globbing things like []? Are these supported mainly because the pattern may be coming from user input, or because internally the match implementation can be more efficient? If the latter, I'm not sure it is worth even having a glob pattern type. If the former, then supporting as many shell-isms as possible is probably useful. I don't think we want to have a globbing class in Qt and I don't want to write it in QString either. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QWebsocket remark
Hi, had a quick look into the implementation as I wanted to use it in my existing webserver. However, the API does not provide a way to use it for an _existing_ tcp communication channel. What would be great is if you modify QWebSocketDataProcessor in some way so that it just get's data from anywhere and therefore also make it a public class. I see it's currently reading from an QIODevice which should be ok, but what is unfortunate is that QWebSocketFrame::readFrame(pIoDevice); blocks! The problem is exactly what you already wrote as comment there: case PS_WAIT_FOR_MORE_DATA: //TODO: waitForReadyRead should really be changed //now, when a websocket is used in a GUI thread //the GUI will hang for at most 5 seconds //maybe, a QStateMachine should be used -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments This mail was not scanned before sending. It was sent from a secure Linux desktop. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about deferred delete handling in sendPostedEvents
I was looking at a problem regarding deferred deletes causing a crash inside nested loops and it was pointed out that in QCoreApplication::setPostedEvents() there is some code there that determines whether it is safe to delete the object or not. From my understanding it will only delete an object if the loop level that it was called from is greater than the current one. However it seems that if the loop level is 0 (i.e. main event loop I guess) and the current one is higher than 0 it deletes anyway, is this the correct intention? Does anyone know why this is safe if so? For reference the code is this bit specifically: const bool allowDeferredDelete = (loopLevel data-loopLevel || (!loopLevel data-loopLevel 0) || (event_type == QEvent::DeferredDelete loopLevel == data-loopLevel)); Where loopLevel is 0 but data-loopLevel is greater than 0. Loop level equal to 0 means the object was deleteLater'ed in main(), before exec(). That is, when no event loop was started. That means any event loop level can delete it. Otherwise, the object is only deleted if you're running a loop with equal or *lower* nesting level than when it was deleteLater'ed. Aha, this does make a lot of sense, thanks this is very useful to know :) Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] New snapshot build from Qt 4.8.6 with mingw4.8.2 installer
Hi all, New snapshot build from Qt 4.8.6 available: http://download.qt-project.org/snapshots/qt/4.8/2014-02-17_484/ Packages are built against sha1 ed792d7b7cd64bce0168b4e509337a8e0408300e fix crash when using GTK 2.14 function in old gtk Could you please verify these packages and report possible new bugs to bugreports.qt-project.org? This snapshot has Windows installer with Qt 4.8 built against mingw gcc 4.8.2 (i686-4.8.2-release-posix-dwarf-rt_v3-rev2.7z from http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.2/threads-posix/dwarf/i686-4.8.2-release-posix-dwarf-rt_v3-rev2.7z/download). There are known packaging related issues with qt-opensource-windows-x86-mingw482-4.8.6-2014-02-17-484.exe: * Installer text refers to mingw 4.4 version instead of 4.8.2: This package requires MinGW with GCC 4.4. Please specify a directory where to find the installation (for instance: C:\MinGW) * Installer will show error message after specifying mingw 4.8.2 installation directory: There is a problem with your MinGW installation: The installer could not find a valid C:\mingw482\mingw32\include\w32api.h (Only versions with W32API 3.13 are supported) Do you still want to continue? (Your installation may not work) Ignore error by selecting Yes and installation starts. * After installation is finished prebuild binaries (assistant, designer etc) won't start because - [Qt486-install-dir]\bin\libstdc++-6.dll wrong version - [Qt486-install-dir]\bin\libwinpthread-1.dll file is missing Copy those two dll -libraries from 686-4.8.2-release-posix-dwarf-rt_v3-rev2 package as workaround to temporarily fix this issue. Br, Akseli -- Akseli Salovaara Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Plans for printing in 5.3 onwards
On 17 February 2014 14:04, Knoll Lars lars.kn...@digia.com wrote: I¹ve been discussing a bit with Friedemann and Andy on IRC, and I¹m willing to give this change set an exception to the feature freeze. The reason is that I believe that this significantly improves our level of support in this area, and that the patch set is almost there. The API is pretty much ok now, so there won¹t be a lot more changes coming anymore. The main thing that¹s missing is bug fixing certain areas, and that¹s what the stabilisation period is there for. So please go ahead with your changes so that we can get them in within the next few days. OK, thanks Lars :-) I now have a version of the Mac code that runs and passes repeated tests on 10.7 so I'll post that up tonight for testing, so hopefully we can rebase to stable and merge once the the repos reopen. Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: merge stable into release and dev into stable
Hi, The declarative merge is still pending, regressions are preventing integration :( I'll look into those first thing tomorrow morning. On the upside, QQuickWidget made it. Simon Opprinnelig melding Fra: Heikkinen Jani Sendt: 14:08 mandag 17. februar 2014 Til: Knoll Lars; Hausmann Simon; development@qt-project.org Kopi: releas...@qt-project.org; Paaso Matti Emne: RE: [Development] HEADS UP: merge stable into release and dev into stable Hi all! I think we need to get merge done as soon as possible to make branches etc clear for everyone. That's why I propose to 1. Finalize those merges from stable to dev as soon as possible https://codereview.qt-project.org/#change,78341 https://codereview.qt-project.org/#change,78333 (Integrating) https://codereview.qt-project.org/#change,77965(Integrating) 2. do the merge from dev to stable tomorrow morning 3. re-target remaining changes related to GL switching, QQuickWidget and the printing patch series to the stable branch Br, Jani -Original Message- From: Knoll Lars Sent: 17. helmikuuta 2014 14:50 To: Hausmann Simon; development@qt-project.org Cc: Heikkinen Jani; releas...@qt-project.org; Paaso Matti Subject: Re: [Development] HEADS UP: merge stable into release and dev into stable On 17/02/14 13:01, Simon Hausmann simon.hausm...@digia.com wrote: On Monday 17. February 2014 07.16.12 Heikkinen Jani wrote: Hi all, It seems we cannot start merge from dev branch to stable at the moment because there is still some issues to be solved before that: 1. There seems to be compilation break in dev branch, see https://codereview.qt-project.org/#change,78283. That needs to be solved first This is solved now :) 2. There is still some merges ongoing from stable to dev branch *https://codereview.qt-project.org/#change,77965 *https://codereview.qt-project.org/#change,77972 *https://codereview.qt-project.org/#change,77977 *https://codereview.qt-project.org/#change,77258 3. Adding qtwebsockets as a submodule is still ongoing, see https://codereview.qt-project.org/#change,76844 For the sake of coordination, with regards to qtdeclarative: * I have a merge from stable to dev prepared that resolves the conflicts. After that you should be able to do the final merge yourself (should be a fast- forward if any) * However at the same time we have two big pending changes, currently targetted for dev, that we've been trying to integrate over the weekend: * QtQuickWidget * Support for GL switching (Dynamic GL patch) So we have three patches that need to go in: The merge, the QtQuickWidget changes and the dynamic GL changes. I suggest we try QtQuickWidget and Laszlo's GL changes first, and when those are in, then I'll try to stage the merge. If anyone else has other changes for qtdeclarative, please consider holding back and consider re-targetting to stable after the project branch or speak up :). Staging of unrelated changes will just slow down the process. Otherwise, let's also coordinate in #qt-labs. There are also the pending printer changes from John, that is pending. As we would like to do the branching to stable as soon as possible, So I¹m ok if GL switching, QQuickWidget and the printing patch series get pushed to stable after the merge as an exception to the feature freeze. But ideally we manage to get at least some of them in before. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
