PropertiesChanged signal

Havoc Pennington havoc.pennington at
Tue May 11 07:13:59 PDT 2010

People are sure quick to identify design flaws that I avoided from day  
1 :-)

There are plenty of real flaws to fix!

On May 7, 2010, at 5:10 PM, Michael 'Mickey' Lauer <mickey at 
 > wrote:

> Am Freitag, den 07.05.2010, 21:53 +0200 schrieb Thiago Macieira:
>> Em Sexta-feira 7. Maio 2010, às 19.06.16, David Zeuthen escreveu:
>>> Many people have asked for a generic mechanism to convey that one or
>>> more properties has changed on an object so they don't have to roll
>>> their own signals for this. Attached is a spec patch to define  
>>> such a
>>> mechanism. Some notes
>>> - this new signal is optional
>>> - even if implemented, a service may opt to avoid using it for huge
>>> properties (e.g. probably want to avoid using it on a a 300 element
>>> a{i{tt}ss} property called ChatRoomParticipants)
>> I will not implement this property in QtDBus unless there's a  
>> subscribe method
>> to trigger the emission of the signal. Anything else is wasteful.
> And while we're there we could/should also fix the client-based signal
> matching, which is IMO one of the major design flaws in DBus.
> I know that the desktop people don't care, but still...
> -- 
> :M:
> _______________________________________________
> dbus mailing list
> dbus at

More information about the dbus mailing list