Re: [Development] Contribution proposal: Dispatcher class
On Sep 25, 2014, at 4:07 PM, wrote: > >> I think if this feature would be added to QtCore, it should be by extending >> QMetaObject::invoke to work with functors. >> By using Qt::BlockingQueuedConnection that would be very similar to what you >> have done. > > I reported this before in Qt issue tracker. I would really like to see > this implemented. > (ftr: https://bugreports.qt-project.org/browse/QTBUG-37253) -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contribution proposal: Dispatcher class
> I think if this feature would be added to QtCore, it should be by extending > QMetaObject::invoke to work with functors. > By using Qt::BlockingQueuedConnection that would be very similar to what you > have done. I reported this before in Qt issue tracker. I would really like to see this implemented. -- Regards Bernhard Lindner ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contribution proposal: Dispatcher class
Technically it sounds good to me. But would it be consistent with the responsibility of QMetaObject? It doesn't use any metadata from the object passed, unlike the other overloads. On Sep 25, 2014 3:14 PM, "Olivier Goffart" wrote: > On Saturday 20 September 2014 12:41:07 Yam Marcovic wrote: > > Hello, > > > > In my company, we started getting all tangled up with loads of signals > and > > slots for many components. We also have a habit of renaming things as > time > > goes by, and that can also pose a bit of a problem when dealing with > > signals & slots, meta object based invocations, etc. > > > > So, since our compiler supports the relevant features of C++11, I've made > > this class, called Dispatcher, which allowed us to develop multi-threaded > > apps much more easily. Instead of defining many signals and slots, you > > simply make your component extend QObject, and then, since you can use it > > with Qt's multi-threading framework, you can use it with the dispatcher. > > > > Here's the link to my repository on GitHub. It also gives a small usage > > example. > > > > https://github.com/ymarcov/qtdispatcher > > > > Note that I've striven to make it as correct as possible. E.g. if the > > return value is a reference, then you really get that reference, not a > copy > > of it, and same with pointers. Or if it's by value, and the returned > object > > has a move constructor, then it will be used. Stuff like that. It's been > > working very well for quite some time now in my workplace, and used in > > quite critical areas of the code with much success. > > > > Please let me know if you think this could help the Qt project as a > > built-in class. > > > > With best wishes, > > Yam Marcovic > > Hi, > > I think if this feature would be added to QtCore, it should be by extending > QMetaObject::invoke to work with functors. > By using Qt::BlockingQueuedConnection that would be very similar to what > you > have done. > > Regards, > -- > 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] Contribution proposal: Dispatcher class
So let's all upvote https://bugreports.qt-project.org/browse/QTBUG-37253. BTW, the way you've implemented the Dispatcher constructor is off. You can't give it a parent from another thread. You should use QObject::moveToThread() instead. Björn 2014-09-25 14:14 GMT+02:00 Olivier Goffart : > On Saturday 20 September 2014 12:41:07 Yam Marcovic wrote: > > Hello, > > > > In my company, we started getting all tangled up with loads of signals > and > > slots for many components. We also have a habit of renaming things as > time > > goes by, and that can also pose a bit of a problem when dealing with > > signals & slots, meta object based invocations, etc. > > > > So, since our compiler supports the relevant features of C++11, I've made > > this class, called Dispatcher, which allowed us to develop multi-threaded > > apps much more easily. Instead of defining many signals and slots, you > > simply make your component extend QObject, and then, since you can use it > > with Qt's multi-threading framework, you can use it with the dispatcher. > > > > Here's the link to my repository on GitHub. It also gives a small usage > > example. > > > > https://github.com/ymarcov/qtdispatcher > > > > Note that I've striven to make it as correct as possible. E.g. if the > > return value is a reference, then you really get that reference, not a > copy > > of it, and same with pointers. Or if it's by value, and the returned > object > > has a move constructor, then it will be used. Stuff like that. It's been > > working very well for quite some time now in my workplace, and used in > > quite critical areas of the code with much success. > > > > Please let me know if you think this could help the Qt project as a > > built-in class. > > > > With best wishes, > > Yam Marcovic > > Hi, > > I think if this feature would be added to QtCore, it should be by extending > QMetaObject::invoke to work with functors. > By using Qt::BlockingQueuedConnection that would be very similar to what > you > have done. > > Regards, > -- > 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contribution proposal: Dispatcher class
On Saturday 20 September 2014 12:41:07 Yam Marcovic wrote: > Hello, > > In my company, we started getting all tangled up with loads of signals and > slots for many components. We also have a habit of renaming things as time > goes by, and that can also pose a bit of a problem when dealing with > signals & slots, meta object based invocations, etc. > > So, since our compiler supports the relevant features of C++11, I've made > this class, called Dispatcher, which allowed us to develop multi-threaded > apps much more easily. Instead of defining many signals and slots, you > simply make your component extend QObject, and then, since you can use it > with Qt's multi-threading framework, you can use it with the dispatcher. > > Here's the link to my repository on GitHub. It also gives a small usage > example. > > https://github.com/ymarcov/qtdispatcher > > Note that I've striven to make it as correct as possible. E.g. if the > return value is a reference, then you really get that reference, not a copy > of it, and same with pointers. Or if it's by value, and the returned object > has a move constructor, then it will be used. Stuff like that. It's been > working very well for quite some time now in my workplace, and used in > quite critical areas of the code with much success. > > Please let me know if you think this could help the Qt project as a > built-in class. > > With best wishes, > Yam Marcovic Hi, I think if this feature would be added to QtCore, it should be by extending QMetaObject::invoke to work with functors. By using Qt::BlockingQueuedConnection that would be very similar to what you have done. Regards, -- 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] Contribution proposal: Dispatcher class
But say, if I want to submit this as part of QtCore, doesn't that package use one consistent license which I'll have to use? On Sep 24, 2014 3:05 PM, "Tomasz Siekierda" wrote: > On 24 September 2014 11:34, Sune Vuorela wrote: > > On 2014-09-24, Yam Marcovic wrote: > >> However, I will say I don't want to force people to give their sources > away > >> if they use it. > >> > >> So a license along the lines of 'this license is here for formal > purposes; > >> but feel free to do anything you want with this,' is good enough as far > as > >> I'm concerned. > > > > I think the formal way of expressing this is either the MIT, 2 or > > 3-clause BSD licenses. > > > > http://opensource.org/licenses/BSD-3-Clause > > http://opensource.org/licenses/BSD-2-Clause > > http://opensource.org/licenses/mit-license.html > > > > /Sune > > This is probably the simplest you can go: WTFPL > http://www.wtfpl.net/about/ > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contribution proposal: Dispatcher class
On 24 September 2014 11:34, Sune Vuorela wrote: > On 2014-09-24, Yam Marcovic wrote: >> However, I will say I don't want to force people to give their sources away >> if they use it. >> >> So a license along the lines of 'this license is here for formal purposes; >> but feel free to do anything you want with this,' is good enough as far as >> I'm concerned. > > I think the formal way of expressing this is either the MIT, 2 or > 3-clause BSD licenses. > > http://opensource.org/licenses/BSD-3-Clause > http://opensource.org/licenses/BSD-2-Clause > http://opensource.org/licenses/mit-license.html > > /Sune This is probably the simplest you can go: WTFPL http://www.wtfpl.net/about/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contribution proposal: Dispatcher class
On 2014-09-24, Yam Marcovic wrote: > However, I will say I don't want to force people to give their sources away > if they use it. > > So a license along the lines of 'this license is here for formal purposes; > but feel free to do anything you want with this,' is good enough as far as > I'm concerned. I think the formal way of expressing this is either the MIT, 2 or 3-clause BSD licenses. http://opensource.org/licenses/BSD-3-Clause http://opensource.org/licenses/BSD-2-Clause http://opensource.org/licenses/mit-license.html /Sune ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contribution proposal: Dispatcher class
I don't care so much about that. I just think it'd be nice as part of the Qt core library. So I'm open for suggestions. :) However, I will say I don't want to force people to give their sources away if they use it. So a license along the lines of 'this license is here for formal purposes; but feel free to do anything you want with this,' is good enough as far as I'm concerned. On Sep 24, 2014 4:51 AM, "Chris Adams" wrote: > Hello Yam, > > I can think of a couple of places in code I've written where that would be > very useful, personally. > However, when I looked at the repo I couldn't see any license information, > and I'm wondering what license you're planning on releasing it under. > > Cheers, > Chris. > > > https://www.qinetic.com.au/ - Qt And QML User Experience Specialists > > On Sat, Sep 20, 2014 at 7:41 PM, Yam Marcovic wrote: > >> Hello, >> >> In my company, we started getting all tangled up with loads of signals >> and slots for many components. We also have a habit of renaming things as >> time goes by, and that can also pose a bit of a problem when dealing with >> signals & slots, meta object based invocations, etc. >> >> So, since our compiler supports the relevant features of C++11, I've made >> this class, called Dispatcher, which allowed us to develop multi-threaded >> apps much more easily. Instead of defining many signals and slots, you >> simply make your component extend QObject, and then, since you can use it >> with Qt's multi-threading framework, you can use it with the dispatcher. >> >> Here's the link to my repository on GitHub. It also gives a small usage >> example. >> >> https://github.com/ymarcov/qtdispatcher >> >> Note that I've striven to make it as correct as possible. E.g. if the >> return value is a reference, then you really get that reference, not a copy >> of it, and same with pointers. Or if it's by value, and the returned object >> has a move constructor, then it will be used. Stuff like that. It's been >> working very well for quite some time now in my workplace, and used in >> quite critical areas of the code with much success. >> >> Please let me know if you think this could help the Qt project as a >> built-in class. >> >> With best wishes, >> Yam Marcovic >> >> ___ >> 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] Contribution proposal: Dispatcher class
Hello Yam, I can think of a couple of places in code I've written where that would be very useful, personally. However, when I looked at the repo I couldn't see any license information, and I'm wondering what license you're planning on releasing it under. Cheers, Chris. https://www.qinetic.com.au/ - Qt And QML User Experience Specialists On Sat, Sep 20, 2014 at 7:41 PM, Yam Marcovic wrote: > Hello, > > In my company, we started getting all tangled up with loads of signals and > slots for many components. We also have a habit of renaming things as time > goes by, and that can also pose a bit of a problem when dealing with > signals & slots, meta object based invocations, etc. > > So, since our compiler supports the relevant features of C++11, I've made > this class, called Dispatcher, which allowed us to develop multi-threaded > apps much more easily. Instead of defining many signals and slots, you > simply make your component extend QObject, and then, since you can use it > with Qt's multi-threading framework, you can use it with the dispatcher. > > Here's the link to my repository on GitHub. It also gives a small usage > example. > > https://github.com/ymarcov/qtdispatcher > > Note that I've striven to make it as correct as possible. E.g. if the > return value is a reference, then you really get that reference, not a copy > of it, and same with pointers. Or if it's by value, and the returned object > has a move constructor, then it will be used. Stuff like that. It's been > working very well for quite some time now in my workplace, and used in > quite critical areas of the code with much success. > > Please let me know if you think this could help the Qt project as a > built-in class. > > With best wishes, > Yam Marcovic > > ___ > 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] Contribution proposal: Dispatcher class
Hello, In my company, we started getting all tangled up with loads of signals and slots for many components. We also have a habit of renaming things as time goes by, and that can also pose a bit of a problem when dealing with signals & slots, meta object based invocations, etc. So, since our compiler supports the relevant features of C++11, I've made this class, called Dispatcher, which allowed us to develop multi-threaded apps much more easily. Instead of defining many signals and slots, you simply make your component extend QObject, and then, since you can use it with Qt's multi-threading framework, you can use it with the dispatcher. Here's the link to my repository on GitHub. It also gives a small usage example. https://github.com/ymarcov/qtdispatcher Note that I've striven to make it as correct as possible. E.g. if the return value is a reference, then you really get that reference, not a copy of it, and same with pointers. Or if it's by value, and the returned object has a move constructor, then it will be used. Stuff like that. It's been working very well for quite some time now in my workplace, and used in quite critical areas of the code with much success. Please let me know if you think this could help the Qt project as a built-in class. With best wishes, Yam Marcovic ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
