gtg-contributors team mailing list archive

[tkdchen <qcxhome@xxxxxxxxx>]

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