Re: [Development] Contribution proposal: Dispatcher class

2014-09-25 Thread Ziller Eike
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 is

Re: [Development] Contribution proposal: Dispatcher class

2014-09-25 Thread private
> 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 impl

Re: [Development] Contribution proposal: Dispatcher class

2014-09-25 Thread Yam Marcovic
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: > > H

Re: [Development] Contribution proposal: Dispatcher class

2014-09-25 Thread Björn Piltz
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 Sa

Re: [Development] Contribution proposal: Dispatcher class

2014-09-25 Thread 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 > s

Re: [Development] Contribution proposal: Dispatcher class

2014-09-25 Thread Yam Marcovic
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

Re: [Development] Contribution proposal: Dispatcher class

2014-09-24 Thread Tomasz Siekierda
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 y

Re: [Development] Contribution proposal: Dispatcher class

2014-09-24 Thread Sune Vuorela
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 conce

Re: [Development] Contribution proposal: Dispatcher class

2014-09-24 Thread Yam Marcovic
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 fee

Re: [Development] Contribution proposal: Dispatcher class

2014-09-23 Thread Chris Adams
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.

[Development] Contribution proposal: Dispatcher class

2014-09-23 Thread Yam Marcovic
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 comp