Re: [Development] Signals/slots for class templates (Was: Evolving Qt's multithreading API)
On Monday 18 March 2013 07:49:07 Thiago Macieira wrote: We are talking about it. As the one who says -2, you are the one who is supposed to state your objections. Can you tell us more about the long-term plan? At first, it is an experiment to see what we can do. It can be used in applications code for internal classes. Then we can see how we can do to have the generated code installed and working. What do you plan on documenting? What can people depend on? Good point. The documentation is still missing. Will you make moc's output files respect source- and binary-compatibility? Yes, this need changes. We will have to split the generated file in two part. One that is included by the header containing the QObject, and one that is just linked with the code like the current code. Peter's patch already does that. We will also have to see which symbol need to be exported and how to do that. (Symbols like qt_meta_stringdata_XXX and qt_meta_data_XXX will have to be exported) We currently rely on the QMetaObject's revision to know at runtime which version of moc was used. But in the case where some code stays inlined with the application, we will have to consider that even newer metaobject may still have an old qt_meta_call implementation. Then the main question is weather this is all worth it? Do we want to support templated QObject? It is perhaps not that useful. But there are some good use cases still. The intemview-ng needed to work around it. QFutureWatcher as well. One of the often heard criticism of moc is that it does not handle template objects. I think it is worth trying. Now the problem is that templates are mostly useful in libraries. And should we support template object if we don't support them yet for libraries? I'd say yes, it is better than nothing. And we can see if there is good use cases. -- 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] Signals/slots for class templates (Was: Evolving Qt's multithreading API)
On terça-feira, 19 de março de 2013 15.02.35, Olivier Goffart wrote: On Monday 18 March 2013 07:49:07 Thiago Macieira wrote: We are talking about it. As the one who says -2, you are the one who is supposed to state your objections. I did. I said I wanted to discuss this more before it went in. I said waiting for 5.2 would be better. It was implied that we need more testing and more understanding of the consequences. Can you tell us more about the long-term plan? At first, it is an experiment to see what we can do. When do you plan on making it non-experimental? It can be used in applications code for internal classes. Then we can see how we can do to have the generated code installed and working. What do you plan on documenting? What can people depend on? Good point. The documentation is still missing. Indeed, but that was not my question. I wasn't asking if you were planning on documenting or when. I was wondering what details you were planning on documenting so that people could use, and what details you'd keep private until we have a better understanding. Will you make moc's output files respect source- and binary-compatibility? Yes, this need changes. We will have to split the generated file in two part. One that is included by the header containing the QObject, and one that is just linked with the code like the current code. Peter's patch already does that. We will also have to see which symbol need to be exported and how to do that. (Symbols like qt_meta_stringdata_XXX and qt_meta_data_XXX will have to be exported) Those methods are static. Exporting them is probably a bad idea. We currently rely on the QMetaObject's revision to know at runtime which version of moc was used. But in the case where some code stays inlined with the application, we will have to consider that even newer metaobject may still have an old qt_meta_call implementation. Note that as merge-at-runtime objects, you may get the string table from one implementation and the methods from another. Please take a moment to consider the consequences of this. Then the main question is weather this is all worth it? Do we want to support templated QObject? Indeed, good questions. It is perhaps not that useful. But there are some good use cases still. The intemview-ng needed to work around it. QFutureWatcher as well. One of the often heard criticism of moc is that it does not handle template objects. I think it is worth trying. Now the problem is that templates are mostly useful in libraries. And should we support template object if we don't support them yet for libraries? I'd say yes, it is better than nothing. And we can see if there is good use cases. And I welcome you for trying so we can learn more. You should blog about it, saying you're experimenting. I'll be happy to look into it too. That doesn't mean the code needs to go into Qt 5.1. In fact, everything you've said so far is a clear indication it should not go into 5.1. -- 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] Signals/slots for class templates (Was: Evolving Qt's multithreading API)
On 3/17/13 5:21 PM, Olivier Goffart oliv...@woboq.com wrote: On Sunday 17 March 2013 08:13:21 Thiago Macieira wrote: On domingo, 17 de março de 2013 11.13.01, Olivier Goffart wrote: On Sunday 10 March 2013 10:09:24 Thiago Macieira wrote: On domingo, 10 de março de 2013 23.54.42, Sze Howe Koh wrote: What's holding us back? What does installing the moc file mean? You install the output from moc. Yes. That is a build system issue which is not difficult to solve. And it's only if the said QObject is in a header file which also needs to be installed, and that you do not rely on extern template. Are you recommending that people use this feature only for non-public classes? I'm saying that it can be used first with non-public classes before we change the build system to install the needed generated files. We're about to start the 5.1 process (ie. branch into stable) etc, and the feature is not blocking anything critical for the release. So I'd say give it some time and let's get it in properly for 5.2. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Signals/slots for class templates (Was: Evolving Qt's multithreading API)
On Monday 18 March 2013 11:35:27 Knoll Lars wrote: We're about to start the 5.1 process About to... but not yet started. So no restrictions applies yet. (ie. branch into stable) etc, and the feature is not blocking anything critical for the release. So I'd say give it some time and let's get it in properly for 5.2. I tought the whole point of the system with dev / stable / release was that dev was never frozen. Point is: even if it is not going to be in 5.1, it is not a reason to refuse talking about it. -- 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] Signals/slots for class templates (Was: Evolving Qt's multithreading API)
On segunda-feira, 18 de março de 2013 15.16.34, Olivier Goffart wrote: On Monday 18 March 2013 11:35:27 Knoll Lars wrote: We're about to start the 5.1 process About to... but not yet started. So no restrictions applies yet. Correct. Since you are done, you could integrate. But here's the maintainer kindly asking you not to, so we have more time to understand the consequences. (ie. branch into stable) etc, and the feature is not blocking anything critical for the release. So I'd say give it some time and let's get it in properly for 5.2. I tought the whole point of the system with dev / stable / release was that dev was never frozen. It isn't frozen. Point is: even if it is not going to be in 5.1, it is not a reason to refuse talking about it. We are talking about it. Can you tell us more about the long-term plan? What do you plan on documenting? What can people depend on? Will you make moc's output files respect source- and binary-compatibility? -- 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] Signals/slots for class templates (Was: Evolving Qt's multithreading API)
On Sunday 10 March 2013 18:27:30 Peter Kümmel wrote: On 10.03.2013 16:54, Sze Howe Koh wrote: Olivier started implementing this: https://codereview.qt-project.org/#change,49864 Last year I gave it also a try, http://lists.qt-project.org/pipermail/development/2012-June/004580.html http://lists.qt-project.org/pipermail/development/2012-June/004536.html and in meantime I've ported it to Qt5: https://codereview.qt-project.org/#change,41468 Sorry. I had forgotten your attempt. The good thing with your attempt is that it splits the output into two files (The part that need to be included and the part that do not). Another problem is that you have to moc before you compile any file which needs the moc generated headers. That's a small build system issue. -- 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] Signals/slots for class templates (Was: Evolving Qt's multithreading API)
On domingo, 17 de março de 2013 11.13.01, Olivier Goffart wrote: On Sunday 10 March 2013 10:09:24 Thiago Macieira wrote: On domingo, 10 de março de 2013 23.54.42, Sze Howe Koh wrote: What's holding us back? What does installing the moc file mean? You install the output from moc. Yes. That is a build system issue which is not difficult to solve. And it's only if the said QObject is in a header file which also needs to be installed, and that you do not rely on extern template. Are you recommending that people use this feature only for non-public classes? -- 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] Signals/slots for class templates (Was: Evolving Qt's multithreading API)
On Sunday 17 March 2013 08:13:21 Thiago Macieira wrote: On domingo, 17 de março de 2013 11.13.01, Olivier Goffart wrote: On Sunday 10 March 2013 10:09:24 Thiago Macieira wrote: On domingo, 10 de março de 2013 23.54.42, Sze Howe Koh wrote: What's holding us back? What does installing the moc file mean? You install the output from moc. Yes. That is a build system issue which is not difficult to solve. And it's only if the said QObject is in a header file which also needs to be installed, and that you do not rely on extern template. Are you recommending that people use this feature only for non-public classes? I'm saying that it can be used first with non-public classes before we change the build system to install the needed generated files. -- 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
[Development] Signals/slots for class templates (Was: Evolving Qt's multithreading API)
On 5 March 2013 05:37, Corentin Jabot corentin.ja...@gmail.com wrote: 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 Olivier started implementing this: https://codereview.qt-project.org/#change,49864 Thiago replied, It needs a lot more discussing. I'm not sure we want it. First and foremost, it requires installing the moc file. Let the discussion begin :) What's holding us back? What does installing the moc file mean? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Signals/slots for class templates (Was: Evolving Qt's multithreading API)
On domingo, 10 de março de 2013 23.54.42, Sze Howe Koh wrote: What's holding us back? What does installing the moc file mean? You install the output from moc. -- 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] Signals/slots for class templates (Was: Evolving Qt's multithreading API)
On 10.03.2013 16:54, Sze Howe Koh wrote: Olivier started implementing this: https://codereview.qt-project.org/#change,49864 Last year I gave it also a try, http://lists.qt-project.org/pipermail/development/2012-June/004580.html http://lists.qt-project.org/pipermail/development/2012-June/004536.html and in meantime I've ported it to Qt5: https://codereview.qt-project.org/#change,41468 Another problem is that you have to moc before you compile any file which needs the moc generated headers. Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
