Re: [Development] Disconnect Signal 0
On Fri, Mar 8, 2013 at 1:48 AM, Thiago Macieira wrote: > Effectively, disconnectNotify will get a null pointer (Qt4) or an invalid > QMetaMethod (Qt5) to mean that all signals are being disconnected. The > receiver needs to deal with it. So wildcard arguments are detected at QDBusAbstractInterface::disconnectNotify in this case and it iterates over all signal names to pass them along, right? David E. Narváez ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disconnect Signal 0
On sexta-feira, 8 de março de 2013 07.29.16, Olivier Goffart wrote: > I think it is best to handle properly the cases in each reimplementation of > disconnectNotify. Effectively, disconnectNotify will get a null pointer (Qt4) or an invalid QMetaMethod (Qt5) to mean that all signals are being disconnected. The receiver needs to deal with it. -- 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] Disconnect Signal 0
On Thursday 07 March 2013 23:58:36 David Narvaez wrote: > Hi all, > > I was taking a look at bug 29498[0] and the explanation is pretty > clear on what's happening: disconnect admits char * signal = 0 as a > parameter (which means all signals) but then forwards that parameter > to other calls that apparently do not commit to support 0 as a > possible value. > > I can take care of this bug but the question is how do we prefer to > fix it: should we multiplex at QObject::disconnect level or start > looking around to support signal = 0 in all other places? > > David E. Narváez > > [0] https://bugreports.qt-project.org/browse/QTBUG-29498 There are ùmore problems with disconnectNotify. It is not called when passing 0, and it is also not called when the sender is destroyed. There was changes in Qt5 about diconnectNotify. It does not really make sens to dispatch at disconnect level in Qt4 because that would be slow as one need to reconstruct all the char*. In Qt5 perhaps we could, but it would still be a small slow down. I think it is best to handle properly the cases in each reimplementation of disconnectNotify. -- 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] Disconnect Signal 0
Hi all, I was taking a look at bug 29498[0] and the explanation is pretty clear on what's happening: disconnect admits char * signal = 0 as a parameter (which means all signals) but then forwards that parameter to other calls that apparently do not commit to support 0 as a possible value. I can take care of this bug but the question is how do we prefer to fix it: should we multiplex at QObject::disconnect level or start looking around to support signal = 0 in all other places? David E. Narváez [0] https://bugreports.qt-project.org/browse/QTBUG-29498 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
