If you add a signal receiver using the following code: sessionBus.add_signal_receiver(dbus_callback,"MessageReading","org.gnome.evolution.mail.dbus.Signal",None,"/org/gnome/evolution/mail/newmail") the _signal_func should match signal events the same way as if you had used: sessionBus.add_signal_receiver(dbus_callback,"MessageReading","org.gnome.evolution.mail.dbus.Signal",":1.12","/org/gnome/evolution/mail/newmail") An optional parameter should function as a wildcard, therefore the code in Dbus._signal_func: if (self._match_rule_to_receivers.has_key(match_rule)): should be refactored as it doesn't work with wildcards.
Created attachment 2638 [details] [review] Patch for proposed feature This patch enables the use of a wildcard for the service when registering a signal handler. If the developer passes None as the service value, when a signal is raised and we're looking for handlers the service is ignored. This is most useful, for example, to deal with Evolution notifications since the service seems to change everytime you start Evolution after shutting it down.
Yep, I was going to get around to fixing this. Will look at the patch and see if it can be applied.
At first glance the patch looks good but is applied to the older version of the bindings. I am going to port it to the new bindings today. There is little chance it will be applied to older bindings.
The algorithm is going to take scale very badly as the number of signal handlers and signals increase. Since the only optional bit is the service, why not simply try the existing dictionary lookup with and without the ";service=:1.45" bit, and call all receivers that match either? Or, if other bits are also optional, do lookups for the combinations that are allowed. Python dictionary comparisions are *very* fast. Walking through a list and calling custom __cmp__ rules is going to be very much slower, particularly if the number of signals and handlers increases.
I'm just going to hash them with None = '*'. I don't see any value in making only one element optional so they all will be.
(In reply to comment #4) By all means, optimize or change the patch I proposed :-) I'm still starting on python development so most of the stuff you mentioned are way over my head. Have you committed the changes so I can take a peek?
I ended up going wild and creating a tree lookup. It was fun. Anyway regular lookup without wildcards should be O(4) or something like that I think worst case depends on the number of matches you have for the signal. I don't know I failed that class ;-) but it is better than liniar for huge sets and only marginally slower for smaller sets. Test it out and see what you think.
*** Bug 3374 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.