Open Bug 1051901 Opened 11 years ago Updated 2 years ago

Status bar: Implement message queue widget (replacing single status label and unlabeled progress bar)

Categories

(Thunderbird :: Mail Window Front End, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: krichter, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release) Build ID: 20140715214327 Steps to reproduce: It would be nice to change (in the longterm planning) the current usage of a single message label (e.g. indicating "Searching..." for the quick search widget) and the unlabeled progress bar by a message queue which gives an overview over currently running tasks (each with a separate label and a progress bar) whose entries appear when they are done (evolution does this or at least tries to it (a lot of tasks seem to be buggy and never terminate, so don't take this as a too exact example ;) ), also KDE has a system notification service and a very similar widget)
Blocks: 1051588
This seems to be quite far implemented in the activity overview panel, but it should not only be transformed into a widget which can be docked somewhere instead of having to deal with a separate window. The removal/replacement of the activity label and the unlabeled progress bar - which appears to be a far reaching design error for me - is as well crucial.
Thanks krichter! Yeah, this is a really nice idea, to have an interactive status bar widget where users can get at the history of status bar messages which currently just flicker for split seconds. It's also true that the single progress bar on the right side of status bar is somewhat disconnected from the actual status message, which combined with the single status message flicker makes it all but impossible to tell the action represented by the progress bar. Something like this was in the pipe for TB3, but only made it half the way (Tools > Activity Manager); see bug 476487 which has the same idea but without much detail. I'll confirm this for now to keep on the radar, we could keep this if we get some traction here, otherwise dupe e.g. to bug 476487.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
See Also: → 476487
Summary: introduce message queue widget (replacing single status label and unlabeled progress bar) → Status bar: Implement message queue widget (replacing single status label and unlabeled progress bar)
Version: 31 → unspecified
Another issue on which this enhancement depends are activities which run unmonitored by the status label and progress bar, e.g. offline synchronization of IMAP folders. I don't want to report a bug at this point, because I guess someone with with good overview over architecture of TB will have to struggle a lot less with than me and will know what different functions have to be put under unified monitoring as described above.
Blocks: 1054950
No longer blocks: 1054950
The code needed to implement the Activity manager seems too complicated for what it does and adding new messages to it is very hard. On the status bar, we can output any message/string we want just by one command in the code. So I would not like complicating status bar too much. However I think implementing status bar history (e.g. like Lotus Notes has) would go a long way in the user control that is requested here.
This just needs some thought about which messages to store in the history (ideally last X ones), or whether to collapse some into 1 entry. Because you probably do not want the 1000 occurrences of "Downloading messages X of 1000..." push away all the other useful messages from other server connecting in parallel that is timing out.
Right! I think KDE's notification widget can be used as source for inspiration. Similar messages should be collapsed into a group showing the details/singular (1000) tasks in a popup of the group entry. Pushing away of messages isn't solved by that, but the effect reduced. It can be avoided reliably in my opinion by providing sortability by a vaste number of criteria of the entries. In the latter case the user would be able to observe a message by it's id (sequence or UID) without having to care about messages entering the queue (assuming the scroll pane is implemented well).
See Also: → 524314
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.