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
> 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
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
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
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
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
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
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
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
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.
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
11 matches
Mail list logo