> IIRC the reason we have it like this is because we didn't want to force the lenses to populate all properties right on the spot when they were activated.
That would be pretty dangerous - it'd imply that lenses are fully operational only after a InfoRequest() call, but because of dbus-activation the first method call can easily be Search() or even Activate(uri).
> AND! If we're really keen on shaving off context switches I'd rather drop the idea of subscribing to Changed() on each lens proxy, but simply have one single DBus match rule to catch them all (just like pokemon - you gotta catch them all!). Ie. AddMatch("type='signal',interface='com.canonical.Unity.Lens',member='Changed'")
Using standard dbus-properties and their change notification signal would probably fix this automagically.
> IIRC the reason we have it like this is because we didn't want to force the lenses to populate all properties right on the spot when they were activated.
That would be pretty dangerous - it'd imply that lenses are fully operational only after a InfoRequest() call, but because of dbus-activation the first method call can easily be Search() or even Activate(uri).
> AND! If we're really keen on shaving off context switches I'd rather drop the idea of subscribing to Changed() on each lens proxy, but simply have one single DBus match rule to catch them all (just like pokemon - you gotta catch them all!). Ie. AddMatch( "type=' signal' ,interface= 'com.canonical. Unity.Lens' ,member= 'Changed' ")
Using standard dbus-properties and their change notification signal would probably fix this automagically.