Enhance CustomInfoBar to display messages from each backend in threading

[Chenxiong Qi]

During the development of Bugzilla synchronization service, I have to display various messages to tell user what reason a bug link cannot be converted to a real bug. Due to the conversation happens in a separate thread, subsequent messages could be shown before user clicks the Ok button to close info bar. Thus, the implementation of CustomInfoBar faces a new situation. The shown of subsequent message will overwrite the UI elements for previous message, but they are not released as normal. Obviously, other backends may also work in a same way with Bugzilla sync service.

I propose this solution is to handle the situation. New CustomInfoBar has no changes to its API, but supports display messages one by one. Two user stories to describe the solution,

1. when a message coming from a backend to tell user some important things, just show the message in info bar. The previous message with all response buttons if exists will hide.
2. user reads the message and then wants to close the bar, after clicking response button, the whole area of the bar will disappear and previous one appears.

So far, no changes and improvement of the UE emerges in my mind, actually I'm not good at that design. This proposal is just based on current InfoBar behavior.

[Parin Porecha (parinporecha)]

Datastore implements backend mutex so that modifying a task by multiple backends can be avoided at same time.

You can try implementing a similar mutex for infobar messages.
Just like each backend has to get the lock first to edit tasks( with self.datastore.get_backend_mutex(): ), it'll also have to get a lock on infobar.

Subsequent messages will be queued, and when the user closes the bar for one message, the remaining ones will be shown one by one.

[Chenxiong Qi (qcxhome)]

On Sat, Jan 25, 2014 at 9:00 PM, Parin Porecha <email address hidden> wrote:
> Datastore implements backend mutex so that modifying a task by multiple
> backends can be avoided at same time.
>
> You can try implementing a similar mutex for infobar messages.
> Just like each backend has to get the lock first to edit tasks( with self.datastore.get_backend_mutex(): ), it'll also have to get a lock on infobar.
>
> Subsequent messages will be queued, and when the user closes the bar for
> one message, the remaining ones will be shown one by one.
>

Hi Parin,

Thanks for your remind. will push the code to the bugzilla sync service branch.

Regards,
Chenxiong Qi

> ** Changed in: gtg
> Status: New => Triaged
>
> ** Changed in: gtg
> Importance: Undecided => Low
>
> ** Changed in: gtg
> Milestone: None => 0.4
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1272663
>
> Title:
> Enhance CustomInfoBar to display messages from each backend in
> threading
>
> Status in Getting Things GNOME!:
> Triaged
>
> Bug description:
> During the development of Bugzilla synchronization service, I have to
> display various messages to tell user what reason a bug link cannot be
> converted to a real bug. Due to the conversation happens in a separate
> thread, subsequent messages could be shown before user clicks the Ok
> button to close info bar. Thus, the implementation of CustomInfoBar
> faces a new situation. The shown of subsequent message will overwrite
> the UI elements for previous message, but they are not released as
> normal. Obviously, other backends may also work in a same way with
> Bugzilla sync service.
>
> I propose this solution is to handle the situation. New CustomInfoBar
> has no changes to its API, but supports display messages one by one.
> Two user stories to describe the solution,
>
> 1. when a message coming from a backend to tell user some important things, just show the message in info bar. The previous message with all response buttons if exists will hide.
> 2. user reads the message and then wants to close the bar, after clicking response button, the whole area of the bar will disappear and previous one appears.
>
> So far, no changes and improvement of the UE emerges in my mind,
> actually I'm not good at that design. This proposal is just based on
> current InfoBar behavior.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gtg/+bug/1272663/+subscriptions

--
A Python developer living in Beijing
http://about.me

[Parin Porecha (parinporecha)]

Chenxiong, can I request you to branch https://code.launchpad.net/~gtg-user/gtg/port-to-gtk3-py3 , and copy the code you've written for bugzilla service to it ? (i.e. - port your code to gtk3 and py3).

If you want to maintain one instead of both py2 and py3 branches, please write the rest of your code in the py3 branch.

We'll be merging this branch with trunk shortly. Since your development work is in progress, it'll be easier to port it right now.
When your patch is complete, open a merge request to the above branch (if it's not yet merged).

[Chenxiong Qi (qcxhome)]

On 01/25/2014 10:58 PM, Parin Porecha wrote:
> Chenxiong, can I request you to branch https://code.launchpad.net/~gtg-
> user/gtg/port-to-gtk3-py3 , and copy the code you've written for
> bugzilla service to it ? (i.e. - port your code to gtk3 and py3).
>
> If you want to maintain one instead of both py2 and py3 branches, please
> write the rest of your code in the py3 branch.
>
> We'll be merging this branch with trunk shortly. Since your development work is in progress, it'll be easier to port it right now.
> When your patch is complete, open a merge request to the above branch (if it's not yet merged).
>
Hi Parin,

Could I presume that GTG will only run under Python 3 and Gtk3 after the
version 4.0 (including 4.0)? Do you consider any compatibilities with
Python 2.x, because many systems, such as CentOS, RHEL, Fedora and many
other distros, does not follow the Python 3 closely as far as I know.

By the way, I didn't find the Python3 and Gtk3 version of liblarch.
Could you please point it to me? Thanks!

Regards,
Chenxiong Qi

[Parin Porecha (parinporecha)]

Yeah, it has been ported completely to python3 and gtk3
So, starting from version 3.2 (that was meant specifically for merging the port), it will only run under py3 and gtk3

I think only ArchLinux ships python3 as the default python version, but all the distros do ship python3 alongside 2.7, so that should not be a problem. Gtk3 has been around for >4-5 years, so except the very old legacy systems, GTG should run smoothly.
Nevertheless, we'll release 0.3.2 only for the latest distros. Based on feedback, we can decide if the older ones should get the update or not.

Yeah, sorry I forgot to add the link - github.com/huxuan/liblarch (branch - port-to-gtk3-py3)

[Chenxiong Qi (qcxhome)]

On 01/31/2014 02:25 PM, Parin Porecha wrote:
> Yeah, it has been ported completely to python3 and gtk3
> So, starting from version 3.2 (that was meant specifically for merging the port), it will only run under py3 and gtk3
>
> I think only ArchLinux ships python3 as the default python version, but all the distros do ship python3 alongside 2.7, so that should not be a problem. Gtk3 has been around for >4-5 years, so except the very old legacy systems, GTG should run smoothly.
> Nevertheless, we'll release 0.3.2 only for the latest distros. Based on feedback, we can decide if the older ones should get the update or not.
>
> Yeah, sorry I forgot to add the link - github.com/huxuan/liblarch
> (branch - port-to-gtk3-py3)
>
Hi Parin,

Much clear. Thanks! By the way, GTG 4.0 and newer ones might lose those
users who are using RHEL or CentOS <= 6.x

Regards,
Chenxiong Qi