[Development] Announcement of Copy - A Qt based cross platform sync app

Hey everyone, As someone who has learned a lot on this mailing list, I wanted to let you all know of a project I have been heavily involved in creating this past year. It is called Copy (www.copy.com), and the ui is written entirely in Qt, using a single code base on Mac, Linux

Re: [Development] FW: Preparing Qt 5.0.2 release

On sexta-feira, 22 de fevereiro de 2013 10.52.38, Salovaara Akseli wrote: > Merge from stable to release branch is now done. > Changes that are intended to get in for Qt 5.0.2 need to be pushed into > release branch. Please create the 5.0.3 entry in JIRA, even if we never actually make that relea

Re: [Development] Request for Volunteers - Qt 5.0.2 Testing

On sexta-feira, 22 de fevereiro de 2013 17.59.45, Sébastien Fricker wrote: > will you tag your Qt 5.0.2 RC? Note that we changed again the release procedures after complaints on how we handled 5.0.1. There will be no 5.0.2 tags until the final release. -- Thiago Macieira - thiago.macieira (AT) in

Re: [Development] Request for Volunteers - Qt 5.0.2 Testing

Rafal, will you tag your Qt 5.0.2 RC? If yes, I will provide a coverage report of QtBase between Qt 5.0.1 and this RC Regards, Sébastien Am 22.02.2013 um 10:33 schrieb Motyka Rafal : > Hello, > > We're planning to start Qt 5.0.2 framework testing on the 7th of March 2013, > before the final rel

Re: [Development] Evolving Qt's multithreading API

On sexta-feira, 22 de fevereiro de 2013 19.26.06, Sze Howe Koh wrote: > Actually, I just realized that the open-source "flavour" of TBB is > licensed under GPLv2 (http://threadingbuildingblocks.org/Licensing). > Doesn't that mean that Qt TBB, if it were to become reality, can't be > licensed under

Re: [Development] Evolving Qt's multithreading API

On sexta-feira, 22 de fevereiro de 2013 15.21.50, Olivier Goffart wrote: > Variadic template, we can clearly not rely on it. It only came in MSVC > really recently (patch release in nov 2012) Yes, we can rely on it. That just means MSVC 2012 RTM doesn't get the feature. As Marc put it, "C++98 c

Re: [Development] Evolving Qt's multithreading API

On sexta-feira, 22 de fevereiro de 2013 15.28.44, Corentin Jabot wrote: > 2013/2/22 André Somers > > > If only QFuture allowed you to connect... Unfortunately, it is not a > > QObject > > Oh yeah, I almost forgot that bit. And somehow it looks like the core issue. > I wonder why by the way: > > We

Re: [Development] Evolving Qt's multithreading API

> However, std::function and std::bind were already in tr1, > which AFAIK is already supported by all the compiler we support (Tier1 + Tier2) > (MSVC 2008 and gcc 4.2 have it) For VC 2008 it is part of an add-on pack [1], but it is available. > We could have something like QObject <- QFutureBase

Re: [Development] Setting the priority of bug reports created the Qt Support team

On sexta-feira, 22 de fevereiro de 2013 16.18.13, Michael Hasselmann wrote: > On Fri, 2013-02-22 at 12:15 +, Vladimir Minenko wrote: > > Our motivation for this is very simple: keep Qt bugs going to one place > > and avoid fragmentation. > > But is that really feasible? You'd have to make sure

Re: [Development] Preparing Qt 5.0.2 release

On sexta-feira, 22 de fevereiro de 2013 15.43.57, Oswald Buddenhagen wrote: > On Fri, Feb 22, 2013 at 12:36:07PM +, Shaw Andy wrote: > > Now that the merge has done, doesn't this in effect mean that stable > > is now in reality Qt 5.1.0 based as dev will be merged to stable on > > 15th March? >

Re: [Development] Setting the priority of bug reports created the Qt Support team

On Fri, 2013-02-22 at 12:15 +, Vladimir Minenko wrote: > Our motivation for this is very simple: keep Qt bugs going to one place > and avoid fragmentation. But is that really feasible? You'd have to make sure it's a general Qt problem first and not related to some interaction with Blackberry s

Re: [Development] [Releasing] pushing/staging around branching time (Re: Some CMake patches for 5.0.2)

On Friday, February 22, 2013 15:39:57 Oswald Buddenhagen wrote: > On Fri, Feb 22, 2013 at 03:11:14PM +0100, Stephen Kelly wrote: > > I misunderstood the branch situation for Qt 5.0.2, and I pushed commits to > > stable which need to be in 5.0.2 (specifically > > 7661e39c022f76da34fcd5d38ecb93c86e01

Re: [Development] Preparing Qt 5.0.2 release

On Fri, Feb 22, 2013 at 12:36:07PM +, Shaw Andy wrote: > Now that the merge has done, doesn't this in effect mean that stable > is now in reality Qt 5.1.0 based as dev will be merged to stable on > 15th March? > this may very well happen, yes. it's still a good idea to push fixes to stable: a)

[Development] pushing/staging around branching time (Re: [Releasing] Some CMake patches for 5.0.2)

On Fri, Feb 22, 2013 at 03:11:14PM +0100, Stephen Kelly wrote: > I misunderstood the branch situation for Qt 5.0.2, and I pushed commits to > stable which need to be in 5.0.2 (specifically > 7661e39c022f76da34fcd5d38ecb93c86e01f1b7 and > 7477d50fce9a0008ff4e050285e146ebc0c1e163 which fix a regre

Re: [Development] Evolving Qt's multithreading API

2013/2/22 André Somers > If only QFuture allowed you to connect... Unfortunately, it is not a > QObject Oh yeah, I almost forgot that bit. And somehow it looks like the core issue. I wonder why by the way: We could have something like QObject <- QFutureBase (with all requiered signals/slots) <-

Re: [Development] Evolving Qt's multithreading API

On Friday 22 February 2013 18:57:29 Sze Howe Koh wrote: > I meant variadic templates and std::bind. QtConcurrent::run() uses a > code generator to produce 6 separate templates. In theory, we can > replace all that with 1 variadic template. No code generator, fewer > templates, less maintenance. >

Re: [Development] Evolving Qt's multithreading API

Op 22-2-2013 14:31, Corentin Jabot schreef: >> On second thought, I'm not sure if this would be commonly needed. We >> can make it start immediately instead, BUT this requires a guarantee >> that the first thread can always connect the finished() signal, before >> the new thread runs and finishes.

Re: [Development] Evolving Qt's multithreading API

2013/2/22 Sze Howe Koh : > Yes, that was my original plan. Someone complained that they couldn't > bind a function + arguments to QtConcurrent::run() first, then run it > at a later time. This approach gives them the opportunity to start it > whenever they want. The problem is QtConcurrent does 2

Re: [Development] Qt 5.1 feature set and freeze date

On Wednesday 13 February 2013 08:49:56 Knoll Lars wrote: > * Friday 22. February: If you have a larger feature/feature branch (not > yet merged) that you want to have in the release you must have told the > release team (by mail to releases@) by then. QLockFile is almost ready, I've been revising

Re: [Development] Preparing Qt 5.0.2 release

> Merge from stable to release branch is now done. > Changes that are intended to get in for Qt 5.0.2 need to be pushed into > release branch. Now that the merge has done, doesn't this in effect mean that stable is now in reality Qt 5.1.0 based as dev will be merged to stable on 15th March? If th

Re: [Development] Setting the priority of bug reports created the Qt Support team

On 19.02.13 18:25, "Frederik Gladhorn" wrote: >See also my mail from two weeks ago ([Development] issue tracker rights). > >I think we need to make a few more adjustments and really need more >people >with bug triaging rights. Actually, there is a good reminder, since there were others concerns

Re: [Development] Evolving Qt's multithreading API

Op 22-2-2013 11:57, Sze Howe Koh schreef: > On Feb 22, 2013 12:33 AM, "Olivier Goffart" wrote: >> Some more common use case would be (pseudo-code) >> >> auto watcher = new QFutureWatcher; >> QObject::connect(watcher, SIGNAL(finished()), myObject, SLOT(doStuff())); >> watcher->setFuture(QThrerad::r

Re: [Development] Evolving Qt's multithreading API

On 20 February 2013 22:45, Sze Howe Koh wrote: > Hi all, > > Some time ago there was some talk about improving Qt's multithreading > API. I'm summarizing them here to stop them from fading into > obscurity, and to see if there's any interest in following them up. > > Here are the tasks mentioned:

Re: [Development] Evolving Qt's multithreading API

I'm not sure what you mean. OpenMP, Pthreads and Boost threads are independent; there is no backend here. Anyway, as Thiago mentioned in another post, OpenMP is not supported on all the compilers that Qt supports, so we can't use it in Qt. (http://openmp.org/wp/openmp-compilers/) Regards, Sze-Ho

Re: [Development] Qt 4.6.5 and 4.7.6 release candidates available

On 21 February 2013 12:53, Turunen Tuukka wrote: > > > This is incorrect assumption as we have discussed this before making the > RC1 - it just took a lot of time due to other release creation activities > to continue the releasing work, so it seems that some persons (at least > Thiago) just notic

Re: [Development] Evolving Qt's multithreading API

On Feb 22, 2013 12:33 AM, "Olivier Goffart" wrote: > Some more common use case would be (pseudo-code) > > auto watcher = new QFutureWatcher; > QObject::connect(watcher, SIGNAL(finished()), myObject, SLOT(doStuff())); > watcher->setFuture(QThrerad::run([]() { return computeStuff(); } )); > // who d

[Development] FW: Preparing Qt 5.0.2 release

Hi, Merge from stable to release branch is now done. Changes that are intended to get in for Qt 5.0.2 need to be pushed into release branch. Br, Akseli > -Original Message- > From: Salovaara Akseli > Sent: 18. helmikuuta 2013 13:15 > To: releas...@qt-project.org; development@qt-project.

[Development] Request for Volunteers - Qt 5.0.2 Testing

Hello, We're planning to start Qt 5.0.2 framework testing on the 7th of March 2013, before the final release. I kindly ask all volunteers to send the answer to this email to me (rafal.mot...@digia.com). Any help will be highly appreciated. Best regards, /Raf