Re: [Development] Branch request: wip/itemviews in qtdeclarative

> On 17 Jan 2017, at 14:29, Edward Welbourne wrote: > One branch is dead but should perhaps be archived (i.e. moved to an > out-of-sight namespace): wip/tizen (qtdeclarative, qtsensors, > qtquickcontrols, qtbase). This was brought up before… Tizen still exists and Qt

[Development] [SUGGESTION] (QTIFW-916) Distribute CMake tools as part of the QtSDK

Maybe it's someone who is interesting, or someone wants to help with the implementation.Link:https://bugreports.qt.io/browse/QTIFW-916--Best Regards,Konstantin Podsvirov ___ Development mailing list Development@qt-project.org

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

> -Original Message- > From: Development [mailto:development- > bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Stottlemyer, > Brett (B.S.) > Sent: keskiviikkona 18. tammikuuta 2017 4.52 > To: Oswald Buddenhagen ; > development@qt-project.org >

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

On 1/16/17, 10:14 AM, "Development on behalf of Oswald Buddenhagen" wrote: >of course, it may be that this task is too complex to get right, in >which case qt bindings for specific systems are a more

Re: [Development] Qt 5.8: ICU vs. iconv

Thiago Macieira wrote: > It should have been possible to enable Iconv for QTextCodec and let ICU be > used for QCollator and QTimeZone. Looks like we forgot. But no, please use ICU > instead of iconv anyway. OK, one external dependency to handle everything, makes sense, thanks. R.

Re: [Development] Qt 5.8: ICU vs. iconv

On terça-feira, 17 de janeiro de 2017 22:02:12 PST René J.V. Bertin wrote: > Hi, > > Another quick question: I understand it is no longer possible to configure > Qt to use both iconv and ICU as I've always done (possible without > effect?). Given that neither of the 3 supported iconv variants is

[Development] Qt 5.8: ICU vs. iconv

Hi, Another quick question: I understand it is no longer possible to configure Qt to use both iconv and ICU as I've always done (possible without effect?). Given that neither of the 3 supported iconv variants is accepted when ICU is used I take it that ICU is the preferred alternative. Is that

[Development] QWidget::setWindowState(Qt::WindowStates) vs QWindow::setWindowState(Qt::WindowState)

Hi, I'm looking at the Qt code with intention to fix it so this code QWidget widget; widget.setWindowState(Qt::WindowMaximized); widget.showMinized(); will show the window iconified and when the user (or program) unminimize the window it pops up maximized. This is currently not

Re: [Development] config.summary in Qt 5.8?

Kevin Funk wrote: > -> https://bugreports.qt.io/browse/QTBUG-56225 > -> https://codereview.qt-project.org/#/c/180823/ > Apply the patch and check, I'd say. > > Hope that helps :) Yep, it did, thanks :) R. ___ Development mailing list

Re: [Development] config.summary in Qt 5.8?

On Tuesday, 17 January 2017 18:49:40 CET René J. V. Bertin wrote: > Thiago Macieira wrote: > > No, only for 5.8.1. > > > > For 5.8.0, config.log will have to do. > > Hmmm, I saw the buildsystem got quite a bit of an overhaul so I'm not > surprised. (I *will* be surprised if all my little hacks

Re: [Development] config.summary in Qt 5.8?

Em terça-feira, 17 de janeiro de 2017, às 18:49:40 PST, René J. V. Bertin escreveu: > Thiago Macieira wrote: > > No, only for 5.8.1. > > > > For 5.8.0, config.log will have to do. > > Hmmm, I saw the buildsystem got quite a bit of an overhaul so I'm not > surprised. (I *will* be surprised if

Re: [Development] config.summary in Qt 5.8?

Thiago Macieira wrote: > No, only for 5.8.1. > > For 5.8.0, config.log will have to do. Hmmm, I saw the buildsystem got quite a bit of an overhaul so I'm not surprised. (I *will* be surprised if all my little hacks continue to work...) Maybe the patch to reintroduce config.summary is already

Re: [Development] config.summary in Qt 5.8?

Em terça-feira, 17 de janeiro de 2017, às 17:40:17 PST, René J.V. Bertin escreveu: > Hi, > > Trying the current 5.8.0-rc tarball I notice that the configure step no > longer creates a config.summary file, while it still prints out the > summary. > > Will this be brought back in the final

Re: [Development] Calendar Systems proposal

Em terça-feira, 17 de janeiro de 2017, às 10:22:57 PST, Edward Welbourne escreveu: > Jake Petroules > > > Eddy, "draft" does not do what you think it does. This is why no one can > > see the change. > I think you are addressing the wrong person. > Soroush created the review (as a draft) and

Re: [Development] invokeMethod() with function pointers

Em terça-feira, 17 de janeiro de 2017, às 11:21:56 PST, Grégoire Barbier escreveu: > And maybe lambdas too, if there was a way to choose the thread/eventloop > in which we want the lambda to be executed (but christmas was a few > weeks ago, I should not dream ;-)). If we do this, it should be

[Development] config.summary in Qt 5.8?

Hi, Trying the current 5.8.0-rc tarball I notice that the configure step no longer creates a config.summary file, while it still prints out the summary. Will this be brought back in the final release? I found it very handy... Thanks, R. ___

Re: [Development] Branch request: wip/itemviews in qtdeclarative

I wrote: > Which reminds me, back in August I investigated then-current wip/s: > http://lists.qt-project.org/pipermail/development/2016-August/026859.html and Ossi brought git fetch's -p option to my attention. Most of those mentioned before are still here, but: > Two branches (only in qtbase)

Re: [Development] Branch request: wip/itemviews in qtdeclarative

Not really related to all the branch business going on, but I want to say i'd gladly help and participate in this WIP, wherever that takes place. 2017-01-14 17:06 GMT+01:00 J-P Nurmi : > Hi, > > Nice, looks great! It would be a very welcome contribution. We could > polish and add

Re: [Development] Branch request: wip/itemviews in qtdeclarative

Oswald Buddenhagen: > speaking of how hard is to get branches: the policy is quite clear that > done (and abandoned) branches should be deleted (or moved to a hidden > namespace, if you insist on archiving your throw-away branch). they > aren't, they are piling up. what exactly do you expect in

Re: [Development] invokeMethod() with function pointers

Grégoire Barbier: > Kind of Qt::DirectOrBlockingQueuedConnection. Blocking_DirectOrQueued_Connection, surely. Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

On Mon, Jan 16, 2017 at 09:59:42PM +, J-P Nurmi wrote: > > On 16 Jan 2017, at 16:24, Oswald Buddenhagen > > wrote: > > > > On Sat, Jan 14, 2017 at 12:37:06PM +, J-P Nurmi wrote: > >> Early feedback from the CI system would be invaluable. > >> > > note that

Re: [Development] Calendar Systems proposal

Allan Sandfeld Jensen asked: > Are you aware of KCalenderSystem? Yes - Sergio Martins helpfully brought it up a couple of weeks ago: http://lists.qt-project.org/pipermail/development/2017-January/028241.html Current plan is roughly to upstream it. Debate remains as to whether it should sit

Re: [Development] Calendar Systems proposal

Jake Petroules > Eddy, "draft" does not do what you think it does. This is why no one can see > the change. I think you are addressing the wrong person. Soroush created the review (as a draft) and added me as a reviewer. That enabled me to add Frederic. > Please remove "draft" status and add

Re: [Development] invokeMethod() with function pointers

Le 16/01/2017 à 10:34, Olivier Goffart a écrit : What's the use case for this function? For direct call you better of calling the function directly, and the equivalent of QueuedConnection can be achieved with QTimer::singleShot. Hi. AFAIK there is no other way to call a method across threads