Hi folks, I have added the support of showing message in CustomInfoBar when there is any problem due to invalid bug id. During the past development, I found that current definition of backend-failed signal and implementation of CustomInfoBar had a restriction. That is backend author couldn't pass additional data except backend_id and error_no, they are used to determine hard coded generic messages for DBus and network in CustomInfoBar class definition. It blocked me to implement the behavior I want.
I extended the backend-failed signal and CustomInfoBar to overcome this restriction and make set_error_no work well in threading. 1. Extend backend-failed signal definition I added additional argument named data[1] to backend-failed signal definition and also added keyword argument data with default value None to CustomeInfoBar.__init__. The argument data accepts a dictionary object. With this small change, any backend author could pass backend-specific data including message, and be more extensive to CustomInfoBar do more interesting things that needs more data from backend. In the meanwhile, this change does not break other backends that use CustomeInfoBar to show message. IMHO, defining backend-specific messages far from the backend is not a good way. It'd better hand them to the backend author. 2. Synchronization of showing message in CustomInfoBar Due to backend_bugzilla.py syncs bug information in threading, make on_backend_failed signal handler thread-safe[2]. This applies to any other backends that works in threading. [1] http://bazaar.launchpad.net/~qcxhome/gtg/bugzilla-sync-service/revision/1345/GTG/backends/backendsignals.py [2] http://bazaar.launchpad.net/~qcxhome/gtg/bugzilla-sync-service/revision/1345/GTG/gtk/browser/browser.py Regards, Chenxiong Qi _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
