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 601500 - Should use notifications to display connection errors
Should use notifications to display connection errors
Status: RESOLVED OBSOLETE
Product: empathy
Classification: Core
Component: Notifications
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: empathy-maint
Depends on:
Blocks:
 
 
Reported: 2009-11-11 09:30 UTC by Praveen Thirukonda
Modified: 2011-12-08 12:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Praveen Thirukonda 2009-11-11 09:30:49 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=599176 deals with using the GTK info bar to show errors
but if i have empathy minimized to tray as is done by most users we will never notice connection errors. This is actually a huge problem for me with pidgin.
so please use libnotify notifications to show the errors. also

>what about the way pidgin solves this: they have a different tray icon if one
>account tries to connect. Instead of the current status icon we could display
>something else (maybe the status icon with some modification?)

This is not a good idea for something like say Ubuntu which uses a messaging indicator. and this is the direction which even GNOME 3 is taking iirc.
Comment 1 Guillaume Desmottes 2009-11-11 10:07:05 UTC
I think this could make sense. Atm when you receive a new call (or new conversation) you are notified in 3 ways:
a) an icon is blinking in the contact list
b) the status icon is blinking
c) you receive a libnotify notification

I guess it could make sense to use a status icon and a notifications for connection errors as well.
Comment 2 Jussi Kukkonen 2010-05-28 07:59:11 UTC
(In reply to comment #1)
> I guess it could make sense to use a status icon and a notifications for
> connection errors as well.

This may be true but there is potential for overdoing this: Generic connection problems (say, wireless dropping) may be already notified by someone else -- this is what we do on MeeGo Netbook -- and IMO they should be handled by someone else. Getting more "connection failed" notifications from all applications that were currently connected to the network is probably overkill in that situation.

So, I guess the question is: if transport level connection errors are handled by someone else, are the remaining types of errors significant enough? I'd imagine they are...
Comment 3 Nick Richards 2010-05-28 15:57:36 UTC
Yes, the logic would have to robust enough to check with NM/ConnMan to see if that thinks we have a network connection and only show the notification then. We should also bundle all connection failures into one notification rather than spamming a potentially unlimited number of messages at the user.

So, copy like this:

"Sorry, we can't connect to $protocol because $errormessage."

Would scale to something like this:

"Sorry, we can't connect to $protocol, $procotol and $protocol."
Comment 4 Guillaume Desmottes 2011-12-08 12:26:23 UTC
The Shell does those notifications for us now.