[Development] Access lazy Models from within QML
Hi all, i'm currently in a project where i try to access a lazy C++ model from within QML. The basics are working well but when it comes to setting the currentIndex it becomes a bit odd. If i implemented everything well the lazy model always reports the element count it currently has loaded by rowCount(). If the List comes to the end, it will call canFetchMore() and if true also fetchMore() to get more elements. But when somebody tries to set the currentIndex to something which is currently not loaded into the lazy model, the data will not be loaded automatically and the Highlight set accordingly. I looked it up at the source code and the code of the QML Views are always checking the currentIndex to be smaller than the model's count. Because of this the View rejects the currentIndex instead of trying to load the full content of the model to determine whether the index is really out of bound. Some my question is, is this a Bug in QtDeclarative ? If so what do you think should be the right behavior ? Loading all the content just to check whether the index is in bound seems to me a bit too performance consuming. Do you think a other implementation of lazy models for QML should be done than this should be documented somewhere. Best Regards Dominik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL in Qt 5.1 and onwards
Hi, just thought I would post a quick update on where we stand with this set of features: On 18/12/2012 13:34, Sean Harmer wrote: Hi, I would like to start a discussion on the future level of support for OpenGL enablers in Qt for those that are interested. So here goes... I would like to add in a bunch more OpenGL enablers but am not sure on where to best put them. Some things I have in mind are: 1) Classes that contain member functions for all OpenGL functions of a given version and profile. E.g. no need to use GLEW or similar. WIP version of this at This is now in. You can obtain a pointer to an object containing a member function for every version of the requested OpenGL version by calling QOpenGLContext::versionFunctionsT() where T is the type of object you wish e.g. QOpenGLFunctions_4_3_Core. The OpenGL extension classes have been put into a new static library which requires QT+=openglextensions to be added to your .pro file. With these I think Qt provides everything that GLEW, GLEE and similar provide. 2) An QOpenGLVertexArrayObject class. This would be just a thin wrapper around a VAO with possibly some API to make it easier to use with QOpenGLBuffer and QOpenGLShaderProgram. There is now a QOpenGLVertexArrayObject class. 3) OpenGL occlusion and timing query objects. Again these are good candidates for QtGui I think but if people object they could go into Qt3D again. The timing query object in particular would be valuable for profiling the GPU time spent in rendering QtQuick 2 scenes. Iirc then right now only the CPU time is available in qtdeclarative but that is only half the story for profiling this stuff. Timer queries and a higher-level helper are up for review at https://codereview.qt-project.org/#change,44788 I hope to add occlusion queries for 5.2. 4) Transform feedback object. Another small but useful candidate for inclusion in QtGui. These objects allow you to perform calculations on the GPU and write the results to a bound buffer object before the rasterisation stage. This can be used to perform animation updates for particles or physical simulations on the GPU for example. The output buffer is then used in a second pass to render with the calculated parameters. Would be very nice to integrate with QOpenGLBuffer and QOpenGLShaderProgram again. Not had enough bandwidth to work on this yet but again will hopefully make it in for 5.2. 5) Provide support for Geometry, Tessellation Control, Tessellation Evaluation and Compute Shader support in QOpenGLShaderProgram. I don't see anything contentious with these. They are just extending QOpenGLShader and/or QOpenGLShaderProgram. QOpenGLShaderProgram and QOpenGLShader now support all programmable shader stages offered by OpenGL including compute shaders. The underlying requirements still apply of course so for example compute shaders require an OpenGL 4.3 context (which Qt also makes easy if the platform supports it). 6) Integrate support for the GL_ARB_debug_output extension into the Qt debug message system. Peppe has said he will start to look at this shortly and I think this would be an awesome feature to have available where the extension is supported. My colleague and friend peppe was kind enough to take this on which has resulted in a very useful QOpenGLDebugLogger. See https://codereview.qt-project.org/#change,48660 7) More enabler classes for textures, samplers, and higher-level abstractions. I think these would be good candidates for a Qt3D library, unless someone would really like to see a subset in QtGui. These will also have to wait for 5.2. So all things considered, Qt 5.2 is shaping up to be a nice release with respect to support for OpenGL. Cheers, Sean ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Incorporating Intel Threading Building Blocks into Qt? (Was: Evolving Qt's multithreading API)
On 2/28/13 5:01 PM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 28 de fevereiro de 2013 18.35.23, Sze Howe Koh wrote: On 23 February 2013 00:16, Thiago Macieira thiago.macie...@intel.com wrote: 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 the LGPL? It's GPLv2+exceptions: The source code of Threading Building Blocks is distributed under version 2 of the GNU General Public License, with the so-called runtime exception, as follows (or see any header or implementation file): As a special exception, you may use this file as part of a free software library without restriction. Specifically, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other files to produce an executable, this file does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. I believe it's the same exception as the one in GNU libstdc++ Apparently, one legal team out there came to the conclusion that, if a non-GPL project incorporates TBB, someone with access to the project's source could then re-release the whole project under GPL, even if it was proprietary [1] Some legal team does not help, of course. But I did a little more digging and it looks like the exception is not like libstdc++'s. The one there is a MUCH longer text. It's also not the short text found in GNU classpath. Moreover, I've just noticed it says you may use this file as part of a free software library. That means if you're not doing a free software library, it does not apply. It sounds a bit far-fetched to me, but it would probably be prudent for us to get an official response from Digia's legal team before we go ahead, right? Yup. Bit I can also check with Intel's legal team what the intention was. They may not give a legal opinion, but the people behind TBB might be able to say what their intention was. Also note that TBB is available under a commercial license too. So, TBB is the shiniest at the moment, as it can replace all of QtConcurrent's functionality and more. I'm happy to set up the project to Qt-ify TBB, if people think it's a good idea and if we get a legal green light. The exception above unfortunately doesn't look good enough to me to incorporate the whole thing into Qt, at least not as part of qtbase. I think an add-on based on TBB might be possible. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Alan Alpert as QtDeclarative maintainer
Yes, congratulations. I've also made you the component lead for declarative in Jira now :) Cheers, Lars On 2/28/13 8:44 PM, Alan Alpert 4163654...@gmail.com wrote: It's been 15 working days, so I think it passed. I'll go update the wiki, and triage some declarative bugs ;) . -- Alan Alpert On Tue, Feb 5, 2013 at 1:47 AM, Bache-Wiig Jens jens.bache-w...@digia.com wrote: +1 from me as well. Alan has an excellent overview on everything going on in this module and is still actively following every aspect of its development. I also agree with Lars that we eventually will need to break this beast into smaller more manageable parts as its scope will only continue to grow in the future. Jens On Feb 5, 2013, at 9:02 AM, Sletta Gunnar gunnar.sle...@digia.com wrote: +1 Alan has done a lot of good stuff for QML so far. Looking forward to more good stuff coming :) cheers, GUnnar On Feb 4, 2013, at 6:28 PM, Alan Alpert 4163654...@gmail.com wrote: On Mon, Feb 4, 2013 at 6:19 AM, Knoll Lars lars.kn...@digia.com wrote: Alan has been very proactive and is probably the best person we have for the job right now. So a +1 from my side. But the declarative repo is pretty big and very central to Qt moving forward. So I believe we will need to split up responsibilities further in the longer term. I would at the minimum like to split up on a per module basis, maybe even a bit more fine-grained. So one Maintainer for Qt QML, one for Qt Quick, etc. Agreed, QtQml and QtQuick are both separate modules that are full 'module' sized. As development ramps back up I hope we can find at least one maintainer per module (which is more important than maintainers 'per repository'). Finally, we also need to ask the person in question: Alan, are you willing to take that role, and will your responsibilities in you day job leave you with enough time to act as the maintainer? Yes, I'm willing to take that role. As you might have noticed, a significant part of my day job is working on QML already and my manager is supportive of my spending more time on it to fulfill the maintainer duties. -- Alan Alpert ___ 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 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Andreas Hanssen as Approver
Congratulations Andreas! I should have just fixed the permissions in Jira. Andreas, can you check that you can now edit bugs etc.? Thanks, Lars On 2/28/13 11:29 PM, Laszlo Papp lp...@kde.org wrote: Yes. See these for an examples: https://bugreports.qt-project.org/browse/QTJIRA-195 https://bugreports.qt-project.org/browse/QTJIRA-178 On Thu, Feb 28, 2013 at 8:09 PM, Thiago Macieira thiago.macie...@intel.com wrote: It's been 15 work days. Congratulations Andreas! PS: how does one get the necessary privileges in JIRA? Do we have to create a QTJIRA task? On quarta-feira, 6 de fevereiro de 2013 13.31.40 tel:2013%2013.31.40, Thiago Macieira wrote: Hello Andreas is a long-time Qt developer. For those of you who haven't yet had the pleasure of meeting him, he's the brains behind the original implementation and maintenance of Graphics View. Before that, I remember working with him on the networking classes -- in fact, QSslSocket is also his and George Staikos's. His knowledge is invaluable. You can find him on IRC under the nickname bibr. His dashboards: https://codereview.qt-project.org/#dashboard,1000351 https://codereview.qt-project.org/#dashboard,1001692 More importantly, the list of reviews: https://codereview.qt-project.org/#q,reviewer: %2522Andreas+Aardal+Hanssen%2522,n,z -- Thiago Macieira - thiago.macieira (AT) intel.com http://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 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] QtDriveInfo module in Playground
In general, I think we need to have another look at Qt SystemInfo for 5.2, and get this all sorted. The split between what's in Qt Core and what's in system info is a bit arbitrary, and it would be good to get this sorted and cleared. Cheers, Lars On 3/1/13 11:28 PM, Thiago Macieira thiago.macie...@intel.com wrote: On sábado, 2 de março de 2013 08.20.35, Lorn Potter wrote: systeminfo works on all platforms, mobile or not. I want the QtCore solution to work on all platforms too. I just want less emphasis on mobile (and especially Symbian-inspired) features and more focus on general use-cases. The udisks functionality would have to be removed if moved to core. Why? -- 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Andreas Hanssen as Approver
Thanks Lars and all! Indeed I can! Yohoo! Andreas 2013/3/4 Knoll Lars lars.kn...@digia.com Congratulations Andreas! I should have just fixed the permissions in Jira. Andreas, can you check that you can now edit bugs etc.? Thanks, Lars On 2/28/13 11:29 PM, Laszlo Papp lp...@kde.org wrote: Yes. See these for an examples: https://bugreports.qt-project.org/browse/QTJIRA-195 https://bugreports.qt-project.org/browse/QTJIRA-178 On Thu, Feb 28, 2013 at 8:09 PM, Thiago Macieira thiago.macie...@intel.com wrote: It's been 15 work days. Congratulations Andreas! PS: how does one get the necessary privileges in JIRA? Do we have to create a QTJIRA task? On quarta-feira, 6 de fevereiro de 2013 13.31.40 tel:2013%2013.31.40, Thiago Macieira wrote: Hello Andreas is a long-time Qt developer. For those of you who haven't yet had the pleasure of meeting him, he's the brains behind the original implementation and maintenance of Graphics View. Before that, I remember working with him on the networking classes -- in fact, QSslSocket is also his and George Staikos's. His knowledge is invaluable. You can find him on IRC under the nickname bibr. His dashboards: https://codereview.qt-project.org/#dashboard,1000351 https://codereview.qt-project.org/#dashboard,1001692 More importantly, the list of reviews: https://codereview.qt-project.org/#q,reviewer: %2522Andreas+Aardal+Hanssen%2522,n,z -- Thiago Macieira - thiago.macieira (AT) intel.com http://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 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 -- Andreas Aardal Hanssen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Failure in tst_qwidget
On 03/02/2013 01:06 PM, Olivier Goffart wrote: If i understand the test properly, it waits two seconds for a window to receive some events. But it may very well happen that the seconds are not enough, because the tests are run on some busy virtual machine or because the window manager is busy or anything. [...] Thanks Oliver for the hints. I tried increasing the waiting times, just to see if that could be related, but it didn't help. What seems to reliably help is this: https://codereview.qt-project.org/49655 However, I'm not able to really explain why that wait is needed. Ciao, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Mar 4, 2013, at 8:13 AM, Samuel Rødal samuel.ro...@digia.com wrote: What about things such as offscreen platform plugins used for testing? Or what about a theoretical platform plugin that would stream rendering commands to somewhere else? Imagine running wayland clients on Mac or Windows for instance, with the server being a Linux machine. Or a platform plugin that lets you run your Qt applications inside Second Life. There might be these and other use cases on Windows and Mac in the future, so I wouldn't recommend going back to the Qt 4 way of thinking. I don't think this is a problem in practice since you can run against e.g. Wayland on on Mac and still link against ApplicationServices. Of course, the native conversion functions would be of little use then. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Incorporating Intel Threading Building Blocks into Qt? (Was: Evolving Qt's multithreading API)
On 4 March 2013 18:49, Knoll Lars lars.kn...@digia.com wrote: On 2/28/13 5:01 PM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 28 de fevereiro de 2013 18.35.23, Sze Howe Koh wrote: On 23 February 2013 00:16, Thiago Macieira thiago.macie...@intel.com wrote: Some legal team does not help, of course. But I did a little more digging and it looks like the exception is not like libstdc++'s. The one there is a MUCH longer text. It's also not the short text found in GNU classpath. Moreover, I've just noticed it says you may use this file as part of a free software library. That means if you're not doing a free software library, it does not apply. I read the Intel forums, and some people were convinced that the free software library refers to TBB itself. That's not a legal opinion though. It sounds a bit far-fetched to me, but it would probably be prudent for us to get an official response from Digia's legal team before we go ahead, right? Yup. Bit I can also check with Intel's legal team what the intention was. They may not give a legal opinion, but the people behind TBB might be able to say what their intention was. IIRC, court decisions are based more on what the text says than what the intention behind the text was, unfortunately. Still, I'd be very interested to know their original intention, if they're happy to let you discuss it in public :-) Also note that TBB is available under a commercial license too. Does that mean businesses will pay both Digia AND Intel for licenses to use Qt (with the TBB module) commercially? The exception above unfortunately doesn't look good enough to me to incorporate the whole thing into Qt, at least not as part of qtbase. I think an add-on based on TBB might be possible. Hmm... but if that add-on can only be used under certain restrictions that don't apply to the rest of Qt, I'm not sure we should do the work from the open-source side. Who can we ask for an authoritative verdict? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On 03/04/2013 01:08 PM, Sorvig Morten wrote: On Mar 4, 2013, at 8:13 AM, Samuel Rødal samuel.ro...@digia.com wrote: What about things such as offscreen platform plugins used for testing? Or what about a theoretical platform plugin that would stream rendering commands to somewhere else? Imagine running wayland clients on Mac or Windows for instance, with the server being a Linux machine. Or a platform plugin that lets you run your Qt applications inside Second Life. There might be these and other use cases on Windows and Mac in the future, so I wouldn't recommend going back to the Qt 4 way of thinking. I don't think this is a problem in practice since you can run against e.g. Wayland on on Mac and still link against ApplicationServices. Of course, the native conversion functions would be of little use then. True, so conversion to from plain structures such as CGRect etc is probably not a big deal. Let's however not expose any platform plugin implementation details in the QtCore / QtGui APIs. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
...and no one has answered to the original question of the topic ;) Konstantin 2013/3/4 Knoll Lars lars.kn...@digia.com: In general, I think we need to have another look at Qt SystemInfo for 5.2, and get this all sorted. The split between what's in Qt Core and what's in system info is a bit arbitrary, and it would be good to get this sorted and cleared. Cheers, Lars On 3/1/13 11:28 PM, Thiago Macieira thiago.macie...@intel.com wrote: On sábado, 2 de março de 2013 08.20.35, Lorn Potter wrote: systeminfo works on all platforms, mobile or not. I want the QtCore solution to work on all platforms too. I just want less emphasis on mobile (and especially Symbian-inspired) features and more focus on general use-cases. The udisks functionality would have to be removed if moved to core. Why? -- 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 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] Incorporating Intel Threading Building Blocks into Qt? (Was: Evolving Qt's multithreading API)
On Thursday 28 February 2013 18:35:23 Sze Howe Koh wrote: So, TBB is the shiniest at the moment, as it can replace all of QtConcurrent's functionality and more. I'm happy to set up the project to Qt-ify TBB, if people think it's a good idea and if we get a legal green light. What exactly do you want to use TBB for? Can we not just suggest users to use TBB directly? And just make sure Qt play nice with it. Or do you want to make a wrapper library to qt-ify it? What exactly do you want to qt-ify? Is it only the underscores and naming conventions or is there more to do? Or do you think Qt could use TBB for implementing some of the algorithms within the Qt library? -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
On Mon, Mar 4, 2013 at 11:11 AM, Konstantin Ritt ritt...@gmail.com wrote: ...and no one has answered to the original question of the topic ;) Well, the original request for a playground module does not make any sense to me because it is either QtCore or QtSystems material. I guess Thiago and Lorn will figure out those details... :) Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On 3/4/13 13:16 , Samuel Rødal wrote: On 03/04/2013 01:08 PM, Sorvig Morten wrote: On Mar 4, 2013, at 8:13 AM, Samuel Rødal samuel.ro...@digia.com wrote: What about things such as offscreen platform plugins used for testing? Or what about a theoretical platform plugin that would stream rendering commands to somewhere else? Imagine running wayland clients on Mac or Windows for instance, with the server being a Linux machine. Or a platform plugin that lets you run your Qt applications inside Second Life. There might be these and other use cases on Windows and Mac in the future, so I wouldn't recommend going back to the Qt 4 way of thinking. I don't think this is a problem in practice since you can run against e.g. Wayland on on Mac and still link against ApplicationServices. Of course, the native conversion functions would be of little use then. True, so conversion to from plain structures such as CGRect etc is probably not a big deal. Let's however not expose any platform plugin implementation details in the QtCore / QtGui APIs. Agreed. Also, as a data point, QtCore already links to ApplicationServices. Tor Arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
On 2 March 2013 18:17, Andre Somers an...@familiesomers.nl wrote: Actually, how do you feel about adding an optional _then_ argument to the list of arguments of the functions in QtConcurrent and whatever is decided to replace the QtConcurrent::run feature? Such a _then_ argument could be a slot signature, a function pointer or a lambda function (basically, whatever you can use in the Qt 5 QObject::connect). That would make it quite a bit easier to work with, I think. It would eliminate the need to create (and delete) a QFutureWatcher for a lot of cases. The method you passed into the _then_ argument would be called when the future is ready. It would be very nice if the _then_ argument could optionally have an argument of the return type of QFuture::result. For this to work, QFuture would not need to be a QObject itself, and because you pass in the _then_ argument with the call itself, you don't have the race issues that you get if you need to connect in separate calls after you have already fired off the thread: no need for trampoline objects or the like. Do you mean like the last argument to QTimer::singleShot()? (this needs to be updated to support Qt 5 slots, by the way) Yes, that could work. To make it truly optional though, the main parallel function would have to be pre-bound by the programmer (e.g. using https://codereview.qt-project.org/#change,45294), since the argument list is variable-size. QFutureT runFunction(QFunctionT main, QFunctionS then = NullFunction); Would the extra binding step nullify the convenience of not requiring a signalling object? Or, what if the run-function returns a QFutureWatcher which already has a QFuture attached -- would that ease the burden from the programmer a bit? It's such a shame that template classes can't be meta-objects... otherwise we could emit the return value directly. That would truly be event-driven C++! Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
Op 4-3-2013 16:17, Sze Howe Koh schreef: On 2 March 2013 18:17, Andre Somers an...@familiesomers.nl wrote: Actually, how do you feel about adding an optional _then_ argument to the list of arguments of the functions in QtConcurrent and whatever is decided to replace the QtConcurrent::run feature? Such a _then_ argument could be a slot signature, a function pointer or a lambda function (basically, whatever you can use in the Qt 5 QObject::connect). That would make it quite a bit easier to work with, I think. It would eliminate the need to create (and delete) a QFutureWatcher for a lot of cases. The method you passed into the _then_ argument would be called when the future is ready. It would be very nice if the _then_ argument could optionally have an argument of the return type of QFuture::result. For this to work, QFuture would not need to be a QObject itself, and because you pass in the _then_ argument with the call itself, you don't have the race issues that you get if you need to connect in separate calls after you have already fired off the thread: no need for trampoline objects or the like. Do you mean like the last argument to QTimer::singleShot()? (this needs to be updated to support Qt 5 slots, by the way) Yes, very much like that, but updated to also support the Qt5 like way of connecting. Yes, that could work. To make it truly optional though, the main parallel function would have to be pre-bound by the programmer (e.g. using https://codereview.qt-project.org/#change,45294), since the argument list is variable-size. QFutureT runFunction(QFunctionT main, QFunctionS then = NullFunction); Would the extra binding step nullify the convenience of not requiring a signalling object? It would not quite, but it would be a bit of a let-down. There still is the benefit of not having to worry about race conditions. However, if we modify the syntax a little bit, I think we can avoid the additional binding step: QFutureT runFunction(QFunctionT then, QFunctionT main); QFutureT runFunction(QFuntionvoid then, QFuntionT main); QFutureT runFunction(QFunctionT main); (Copying your use of QFunction, a quick look at the WIP you mentioned doesn't quite reveal to me how it is supposed to work, and I probably use it wrong. The then argument could be lambda function, a QObject* and a slot signature, a pointer to an object and a member function pointer, or perhaps even a plain function pointer. It would be nice if the argument for these could be either no argument at all, or of the type T so it can just receive the value from the method.) Sure, it would read easier to have the _then_ follow the actual method, if if that is not possible, then I would not mind having them be reversed. However - and I am not a template mage - I think it should be possible to keep the order as is? As long as the actual function doesn't take a final argument with the given signature, I don't think there would be confusion? Note that I'd also like to see the same possibity for the other QtConcurrent methods, and pershaps even the threadpool method as well. Or, what if the run-function returns a QFutureWatcher which already has a QFuture attached -- would that ease the burden from the programmer a bit? No, it would not! The returned QFutureWatcher then has unclear ownership. That sounds even worse than having to create one yourself. And: the future still can finish before you have a chance to make the connection between the QFutureWatcher::finished() signal and your own slot. It's such a shame that template classes can't be meta-objects... otherwise we could emit the return value directly. That would truly be event-driven C++! Yeah, that is a very unfortunate artifact of the way Qt implements signals and slots. However, it is what it is... André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
On segunda-feira, 4 de março de 2013 17.25.35, André Somers wrote:
QFutureT runFunction(QFunctionT then, QFunctionT main);
QFutureT runFunction(QFuntionvoid then, QFuntionT main);
QFutureT runFunction(QFunctionT main);
I think this is going too far. If you want to chain jobs, we need a more
complex job tracker. That's what ThreadWeaver is trying to do. But we need to
solve a simpler problem first.
And besides, you can always do:
QFutureWatcherT w = runFunction(...);
w.connect(QFutureWatcherT::finished, []() { other function goes here });
w.connect(QFutureWatcherT::finished, w, QObject::deleteLater);
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
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] Evolving Qt's multithreading API
Op 4-3-2013 21:21, Thiago Macieira schreef:
On segunda-feira, 4 de março de 2013 17.25.35, André Somers wrote:
QFutureT runFunction(QFunctionT then, QFunctionT main);
QFutureT runFunction(QFuntionvoid then, QFuntionT main);
QFutureT runFunction(QFunctionT main);
I think this is going too far. If you want to chain jobs, we need a more
complex job tracker. That's what ThreadWeaver is trying to do. But we need to
solve a simpler problem first.
And besides, you can always do:
QFutureWatcherT w = runFunction(...);
w.connect(QFutureWatcherT::finished, []() { other function goes here });
w.connect(QFutureWatcherT::finished, w, QObject::deleteLater);
The point is not to chain jobs. Indeed, that is what threadweaver is
doing. I am sorry if I did not make the point clear. The point is not to
create complex chains (or really: networks) of jobs. ThreadWeaver
already supports that use case. Still, I suppose you could do something
like that. The lines I wrote however were not meant as a chain, just as
different versions of the same method with a then method taking a
parameter of the type of the function, a then method without a parameter
and a call without any then argument.
The point is to get notification when a job is done in the simples way
possible. Nothing more, nothing less, without having to check the status
of the future. The way I understand QtConcurrent, the work is started
immediately and may finish at any moment. So, by the time I create the
QFutureWatcher and added the connect, the work may already be done.
Right? That means that you have to check for that as well, or you risk
missing the finished signal. See the discussion on the trampoline object
elsewhere in this thread. You'd avoid that by passing what you want
happening directly to the invocation to QtConcurrent.
The resulting code using a then argument would be much simpler than what
you post above. I don't quite get that code at all, by the way. You seem
to be creating a QFutureWatcher on the stack, and still connecting to
its deleteLater method? Also, which method directly returns a
QFutureWatcher? The QtConcurrent I'm familiar with returns a QFutureT,
which you can assign to a QFutureWatcher.
I think the proposed API addition is actually quite natural. It is not
without precedent (QTimer::singleShot()), and would result in quite
simple, readable code. It also doesn't create big constraints on the
type of object returned from these functions: there is no need for them
to be QObjects themselves.
If you want more control or need more information, you'd still create a
QFutureWatcher of course, as it provides more information than a simple
done.
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
Yes, very much like that, but updated to also support the Qt5 like way of connecting. Yes, that could work. To make it truly optional though, the main parallel function would have to be pre-bound by the programmer (e.g. using https://codereview.qt-project.org/#change,45294), since the argument list is variable-size. QFutureT runFunction(QFunctionT main, QFunctionS then = NullFunction); Would the extra binding step nullify the convenience of not requiring a signalling object? It would not quite, but it would be a bit of a let-down. There still is the benefit of not having to worry about race conditions. However, if we modify the syntax a little bit, I think we can avoid the additional binding step: QFutureT runFunction(QFunctionT then, QFunctionT main); QFutureT runFunction(QFuntionvoid then, QFuntionT main); QFutureT runFunction(QFunctionT main); I'm gonna sound crazy but... An important part of the QtConcurrent code do that implicit biding, and if we were to duplicate those calls for different usages, it's a lot of boilerplate code. Also, as said above, it limit the api in the sens that all the require parameters must be put before the actual function and its parameters. Both issues make it harder to maintain and evolve the api. So, what about let the users make the binding part themselves ? The syntax could be like runFunction(QFunctionFoo::bind(myFunction, arg1, arg2)); assuming the biding part is done using a bunch of functions, it could be simplified to runFunction(qBind(myFunction, arg1, arg2)) instead of the actual QtConcurrent::run(myFunction, arg1, arg2) It's arguably less straight forward for the user, but on the other hand, as we will need extra parameters, putting the options/flags/callback/signals before the function and its parameter could be even more confusing. we could then have: runFunction(QFunctionT function, Options, callback) (Copying your use of QFunction, a quick look at the WIP you mentioned doesn't quite reveal to me how it is supposed to work, and I probably use it wrong. QFunction is somehow like std::function, but has support for c++98. It's actually something between std::function and std::bind ( but does not support placeholders ) The then argument could be lambda function, a QObject* and a slot signature, a pointer to an object and a member function pointer, or perhaps even a plain function pointer. It would be nice if the argument for these could be either no argument at all, or of the type T so it can just receive the value from the method.) Agree It's such a shame that template classes can't be meta-objects... otherwise we could emit the return value directly. That would truly be event-driven C++! Yeah, that is a very unfortunate artifact of the way Qt implements signals and slots. However, it is what it is... Would that even be possible ? It sure would be nice Corentin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
On segunda-feira, 4 de março de 2013 22.00.34, Andre Somers wrote: The point is to get notification when a job is done in the simples way possible. Nothing more, nothing less, without having to check the status of the future. I understand what you want, but I don't want that. QFutureWatcher serves that purpose already. I don't quite get that code at all, by the way. You seem to be creating a QFutureWatcher on the stack, and still connecting to its deleteLater method? It was pseudocode. It should have been: QFutureWatcherT *w = new QFutureWatcherT(); w-setFuture(QThread::start(...)); I think the proposed API addition is actually quite natural. It is not without precedent (QTimer::singleShot()), and would result in quite simple, readable code. I disagree on both accounts. It's not natural: there is no precedent for taking two runnables outside of QtConcurrent's own reducing functions (map- reduce and filter-reduce). In that case, it serves a very specific purpose, in a domain where the concept is understood. And besides, that's the very module we're trying to replace. There's also no good API that takes two slots -- the only example I can think of is the horrible QDBusConnection::callWithCallback. And that one is made simpler and easier by QDBusPendingReply and QDBusPendingCallWatcher, two classes inspired by QFuture and QFutureWatcher. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Evolving Qt's multithreading API
On segunda-feira, 4 de março de 2013 14.49.15, Thiago Macieira wrote:
I think the proposed API addition is actually quite natural. It is not
without precedent (QTimer::singleShot()), and would result in quite
simple, readable code.
I disagree on both accounts. It's not natural: there is no precedent for
taking two runnables outside of QtConcurrent's own reducing functions (map-
reduce and filter-reduce). In that case, it serves a very specific purpose,
in a domain where the concept is understood. And besides, that's the very
module we're trying to replace.
There's also no good API that takes two slots -- the only example I can
think of is the horrible QDBusConnection::callWithCallback. And that one
is made simpler and easier by QDBusPendingReply and
QDBusPendingCallWatcher, two classes inspired by QFuture and
QFutureWatcher.
Oh, and if you want simple, one more thing occurred to me:
runFunction([]() { main(); then(); });
If you need the return value:
runFunction([]() { then(main()); });
I will not accept C++11 isn't available for everyone as a reason to add a
more complicated API. The API should be designed for C++11 use and later made
to work with C++98, with as little modification as possible.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
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] Access lazy Models from within QML
whoops, missed reply-all On Mon, Mar 4, 2013 at 4:51 PM, Alan Alpert 4163654...@gmail.com wrote: On Mon, Mar 4, 2013 at 1:36 AM, Dominik Holland dominik.holl...@pelagicore.com wrote: Hi all, i'm currently in a project where i try to access a lazy C++ model from within QML. The basics are working well but when it comes to setting the currentIndex it becomes a bit odd. If i implemented everything well the lazy model always reports the element count it currently has loaded by rowCount(). If the List comes to the end, it will call canFetchMore() and if true also fetchMore() to get more elements. But when somebody tries to set the currentIndex to something which is currently not loaded into the lazy model, the data will not be loaded automatically and the Highlight set accordingly. I looked it up at the source code and the code of the QML Views are always checking the currentIndex to be smaller than the model's count. Because of this the View rejects the currentIndex instead of trying to load the full content of the model to determine whether the index is really out of bound. Some my question is, is this a Bug in QtDeclarative ? If so what do you think should be the right behavior ? Loading all the content just to check whether the index is in bound seems to me a bit too performance consuming. This is not a bug, ListView does not currently support canFetchMore (which only claims to be used by QAbstractItemView, so the docs are accurate already). The behavior if it was supported seems simple: as you scroll near the end the scrollbar jumps, and if you request an index off the end it fetches more until it either reaches the index or can't fetch more. You should file a suggestion in JIRA, long-term I don't see why the QML views should not support this feature. For now, this means that you'll need to manage fetching more data from the model yourself. If you expose the functions to QML, it can be as simple as (inside your ListView): onCurrentIndexChanged: if (currentIndex myModel.count * 0.9 myModel.canFetchMore) myModel.fetchMore(); -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Access lazy Models from within QML
Hi, On 03/05/2013 01:51 AM, Alan Alpert wrote: whoops, missed reply-all On Mon, Mar 4, 2013 at 4:51 PM, Alan Alpert 4163654...@gmail.com wrote: On Mon, Mar 4, 2013 at 1:36 AM, Dominik Holland dominik.holl...@pelagicore.com wrote: Hi all, i'm currently in a project where i try to access a lazy C++ model from within QML. The basics are working well but when it comes to setting the currentIndex it becomes a bit odd. If i implemented everything well the lazy model always reports the element count it currently has loaded by rowCount(). If the List comes to the end, it will call canFetchMore() and if true also fetchMore() to get more elements. But when somebody tries to set the currentIndex to something which is currently not loaded into the lazy model, the data will not be loaded automatically and the Highlight set accordingly. I looked it up at the source code and the code of the QML Views are always checking the currentIndex to be smaller than the model's count. Because of this the View rejects the currentIndex instead of trying to load the full content of the model to determine whether the index is really out of bound. Some my question is, is this a Bug in QtDeclarative ? If so what do you think should be the right behavior ? Loading all the content just to check whether the index is in bound seems to me a bit too performance consuming. This is not a bug, ListView does not currently support canFetchMore (which only claims to be used by QAbstractItemView, so the docs are accurate already). The behavior if it was supported seems simple: as you scroll near the end the scrollbar jumps, and if you request an index off the end it fetches more until it either reaches the index or can't fetch more. You should file a suggestion in JIRA, long-term I don't see why the QML views should not support this feature. Ok will do that... For now, this means that you'll need to manage fetching more data from the model yourself. If you expose the functions to QML, it can be as simple as (inside your ListView): onCurrentIndexChanged: if (currentIndex myModel.count * 0.9 myModel.canFetchMore) myModel.fetchMore(); Yes this makes sense and it's similar to my solution... But why do you need to multiply it with 0.9 ? Dominik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
Op 4-3-2013 23:56, Thiago Macieira schreef:
On segunda-feira, 4 de março de 2013 14.49.15, Thiago Macieira wrote:
I think the proposed API addition is actually quite natural. It is not
without precedent (QTimer::singleShot()), and would result in quite
simple, readable code.
I disagree on both accounts. It's not natural: there is no precedent for
taking two runnables outside of QtConcurrent's own reducing functions (map-
reduce and filter-reduce). In that case, it serves a very specific purpose,
in a domain where the concept is understood. And besides, that's the very
module we're trying to replace.
There's also no good API that takes two slots -- the only example I can
think of is the horrible QDBusConnection::callWithCallback. And that one
is made simpler and easier by QDBusPendingReply and
QDBusPendingCallWatcher, two classes inspired by QFuture and
QFutureWatcher.
Oh, and if you want simple, one more thing occurred to me:
runFunction([]() { main(); then(); });
If you need the return value:
runFunction([]() { then(main()); });
I will not accept C++11 isn't available for everyone as a reason to add a
more complicated API. The API should be designed for C++11 use and later made
to work with C++98, with as little modification as possible.
The above doesn't work at all. It will run the then() in the worker
thread. That is not what you want.
I'd appreciate a reply on the point that when using a QFutureWatcher,
you don't know if the future is already done or not at the moment you
connect.
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
On Mar 4, 2013, at 11:56 PM, Thiago Macieira thiago.macie...@intel.com wrote:
Oh, and if you want simple, one more thing occurred to me:
runFunction([]() { main(); then(); });
If you need the return value:
runFunction([]() { then(main()); });
I will not accept C++11 isn't available for everyone as a reason to add a
more complicated API. The API should be designed for C++11 use and later made
to work with C++98, with as little modification as possible.
I think this is the direction we should go in: build the future API around
C++11 lambdas.
This reduces the need for QFuture and especially QFutureWatcher. Thiago pointed
out the waiting case above. Instead of connecting to
QFutureWatcher::finished(), create a signal and emit when the work is done:
MyObject::asyncWork()
{
runFunction([]() {
Result result = doWork();
emit done(result); // signal on MyObject
});
}
Morten
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
On terça-feira, 5 de março de 2013 08.38.17, André Somers wrote: I'd appreciate a reply on the point that when using a QFutureWatcher, you don't know if the future is already done or not at the moment you connect. It's not done, by construction. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Evolving Qt's multithreading API
On Mar 5, 2013, at 8:38 AM, André Somers an...@familiesomers.nl wrote: I'd appreciate a reply on the point that when using a QFutureWatcher, you don't know if the future is already done or not at the moment you connect. The intended usage of QFutureWatcher is that you set it up with connections before starting the worker thread/task. Then QFutureWatcher::setFuture() will do the correct thing and emit finished() if the future is already done. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
Op 5-3-2013 8:41, Thiago Macieira schreef: On terça-feira, 5 de março de 2013 08.38.17, André Somers wrote: I'd appreciate a reply on the point that when using a QFutureWatcher, you don't know if the future is already done or not at the moment you connect. It's not done, by construction. So, if I understand you correctly, the following is completely safe right? QFuturevoid future = QtConcurrent::run(someFunction, 42, blah); //... perhaps some code, but not returning to the event loop QFutureWatcher* watcher = new QFutureWatcher(this); watcher.setFuture(future); connect(watcher, SIGNAL(finished(), this, SLOT(resultOfSomeFunctionReady())); So, when _does_ the work start for the future then? Because all the documentation for QtConcurrent suggests that the work is started immediately if there is a free thread in the pool. And if the work can indeed start immediately, how is is guaranteed that at the moment you create your watcher your future is not done yet? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
On terça-feira, 5 de março de 2013 08.54.35, André Somers wrote: Op 5-3-2013 8:41, Thiago Macieira schreef: On terça-feira, 5 de março de 2013 08.38.17, André Somers wrote: I'd appreciate a reply on the point that when using a QFutureWatcher, you don't know if the future is already done or not at the moment you connect. It's not done, by construction. So, if I understand you correctly, the following is completely safe right? QFuturevoid future = QtConcurrent::run(someFunction, 42, blah); //... perhaps some code, but not returning to the event loop QFutureWatcher* watcher = new QFutureWatcher(this); watcher.setFuture(future); connect(watcher, SIGNAL(finished(), this, SLOT(resultOfSomeFunctionReady())); Yes. So, when _does_ the work start for the future then? Immediately. In fact, the future might be finished before run() returns. However, it's not notified. Because all the documentation for QtConcurrent suggests that the work is started immediately if there is a free thread in the pool. And if the work can indeed start immediately, how is is guaranteed that at the moment you create your watcher your future is not done yet? By construction. The code was designed so that if you do that, it will still emit finished(). I explained how to achieve this in another email in this thread. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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
