GNOME Bugzilla – Bug 271734
strange message in status bar: 'Working 0x86d6688 (...)'
Last modified: 2007-10-25 18:11:45 UTC
My Evo status bar shows that strange message 'Working 0x86d6688 (...)' in the Mailer no matter what I do. Switching folder, messages etc. does not make it go away.
well, at least it's a known issue, see for example <http://lists.ximian.com/archives/public/evolution/2004-August/038917.html>. you use IMAP, i guess?
perhaps, perhaps related to bug 258663? (also about "working (...)" never going away...
yeah, I got mailboxes configured using IMAP, though none of them is actually being used; all my activated mailboxes use 'Maildir'. hmm, just tried the junk stuff as described in #58663; it seems to be gone now
fixed i guess
This is evolution 2.2.1.1 and I again see Working 0x33d5ba18 (...) in my status bar currently...
Definitely still happens for me. All my mailboxes are IMAP. It seems to happen more regularly when I leave Evolution online for extended periods of time. If I go offline, read my e-mail, and then resync it doesn't seem to happen as often. 2.2.1.1 Ubuntu PPC
Created attachment 46191 [details] Pickture of "Working..." messages This is just a picture to prove I'm not crazy :)
*** Bug 314561 has been marked as a duplicate of this bug. ***
copying comments of duplicate bug 314561 by Benjamin Berg: "Looks like there is a small typo in mail/mail-mt.c:960. This can result in a message in the status bar in the form of "Working 0x4f6db2d3". Replacing the %p with %s should fix this. It also looks like the string is not translatable currently." would like to set target to 2.4 since this is a bug with high visibility, anyway no target milestone existing yet, so putting to 2.5.
so that would be the line what = g_strdup_printf("Working %p", msg); just writing this down because "line 960" changes as time goes by... :-) <http://cvs.gnome.org/viewcvs/evolution/mail/mail-mt.c?r1=1.82&r2=1.83>
Created attachment 51552 [details] [review] untested patch for "Working" statusbar. untested patch to fix the offset display of the "working" message in statusbar; also adds internationalization (hum... really 18 characters between "i" and "n", cool) to the string... :-)
hmm... needs translator comments, i wouldn't now what "working %s" should say if i had to translate that.
Hey andre, thanks for the patch. But 'msg' is not a string its a structure. So %s wont work. IMHO, its best to remove the string or just have "Working..." Although i agree it would be a totally vague message.
partha: so, conclusion? i'd like to fix this for 2.6. just tell me exactly what to do, and keep the translators in mind... :-)
partha: *PING* we're heading string freeze next monday. if we use "Working..." we need a translator comment. proposals?
I vote for just getting rid of the message altogether - I do not see it being very useful for a user.
i uncommented the string in cvs: http://cvs.gnome.org/viewcvs/evolution/mail/mail-mt.c?r1=1.93&r2=1.94 closing as fixed.
The only thing that worries me about the committed patch is that the real problem may not be solved - what's creating worker threads without a description? and why are they never exiting like they should? I just feel that the patch simply hides the real problem...
jeff, you're definitely right. reopen?
The supposed fix (comment#19) introduced a crash. So, reopening the bug and raising the severity. MAIL_MT_UNLOCK (mail_msg_lock); if (msg->ops->describe_msg) what = msg->ops->describe_msg (msg, FALSE); /* uncommenting because message is not very useful for a user, see bug 271734 else { what = g_strdup_printf("Working %p", msg); } */ in the above code, "what" is a char*, that is uninitialized. By commenting out the else part, "what" remains unitialized and crashes in further calls that use "what".
Ok, Partha has reverted back the changes.. the commented lines are uncommented now. Lowering the severity, however, the bug is till open as per comment#18.
changing target milestone from 2.5 to future. sorry, too many bugs, too less time.
Created attachment 64012 [details] [review] Fix There is no use of showing a HEXA-String to the user. Will set it to an empty (not NULL) string. Will not crash/show-cryptic-messages. The original issue of why some unnamed operations are created is still to be found out anyway.
While the Hexa-string made no sense to me either, it always gave me valuable feedback that some activity was still in progress and I would do well to wait or at least not close the app, during some painfully long operations. Setting this to an empty string nudges the usability a few notches below. Again, can we get rid of the unnamed operations instead ?
(In reply to comment #24) > While the Hexa-string made no sense to me either, it always gave me valuable > feedback that some activity was still in progress and I would do well to wait > or at least not close the app, during some painfully long operations. Well, sometimes the hexa string just sits there, while there's no activity. So I'm not sure we can say this is good feedback...
*** Bug 340744 has been marked as a duplicate of this bug. ***
(In reply to comment #25) > Well, sometimes the hexa string just sits there, while there's no activity. So > I'm not sure we can say this is good feedback... I am seeing this now, too. This is perhaps because there is no status update after the activity is complete. This begs a decision from the usability and mail folks. Adding 'usability' keyword and srag to the CC list.
Created attachment 97650 [details] [review] proposed evo patch for evolution; Show description of operation, if available, instead of empty string and end activity properly, if operation ended before/during activity start.
Milan, looks fine to me. Commit to stable/head. (I haven't tested this as I can't reproduce this always).
Committed to trunk. Committed revision 34411. Committed to stable. Committed revision 34412.