On Thu, Jan 9, 2014 at 5:21 PM, Parin Porecha <[email protected]> wrote: > Thats a very nice addition to the backends service ! > > I agree that we should not add backend specific error strings to > backendsignals.py (ERRNO_BUGZILLA_*) > Since it is meant to be a general class, can you please move those strings > to the bugzilla backend ? >
Sure. Actually, all ERRNO_* in backendsignals.py should be removed, as well as moving DBUS_MESSAGE, NETWORK_MESSAGE, and AUTHENTICATION_MESSAGE out of custominfobar.py, after other backends are changed to pass error message via the argument data. Because, ERRNO_* are used for determining what message should be shown. Then, method set_error_code will become more simple. Regards, Chenxiong Qi > > > On Thu, Jan 9, 2014 at 2:14 PM, tkdchen <[email protected]> wrote: >> >> 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 > > > > > -- > Regards, > Parin Porecha > > GTG Developer > GNOME Foundation Member > Github | Launchpad | Gnome Bugzilla | Ohloh -- A Python developer living in Beijing http://about.me _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
