After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 471812 - Don't display hex value in "retrieving message" status text
Don't display hex value in "retrieving message" status text
Status: RESOLVED OBSOLETE
Product: evolution
Classification: Applications
Component: Mailer
2.12.x (obsolete)
Other Linux
: Normal minor
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks: 502515
 
 
Reported: 2007-08-30 12:05 UTC by spark
Modified: 2012-12-30 15:58 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Screenshot (3.41 KB, image/png)
2007-08-30 12:06 UTC, spark 		Details

Description spark 2007-08-30 12:05:46 UTC 
Evolution currently displays something like "Retrieving message 000001e7715f (...)" when it's downloading a message. The hex value and the "(...)" serves no purpose for the user and should be removed. The "(...)" should also be removed from "Formatting message (...)". If this is supposed to display "x% complete" text, it never does here, and is probably unnessecery even if it were to work.

This is using an Exchange account, but probably also applies elsewhere.
Comment 1 spark 2007-08-30 12:06:15 UTC 
Created attachment 94627 [details]
Screenshot
Comment 2 spark 2007-08-30 12:13:14 UTC 
One other thing, the statusbar is an odd place for the GNOME foot icon spinner. I think it only animates when there's network activity since it doesn't do anything when "Formatting message" is shown. If it's supposed to indicate activity, it would probably make more sense for it to be located in the top right corner of the app like Nautilus or Epiphany.
Comment 3 Matthew Barnes 2008-03-11 00:36:20 UTC 
Bumping version to a stable release.
Comment 4 André Klapper 2012-09-21 17:04:06 UTC 
I haven't seen this problem for ages now.
spark: Is this still an issue or can this be closed as RESOLVED OBSOLETE?