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 655753 - Improve offline notification for network outage
Improve offline notification for network outage
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: general
3.0.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2011-08-01 20:28 UTC by Christoph Wickert
Modified: 2012-05-11 13:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed evo patch (3.08 KB, patch)
2011-09-23 13:22 UTC, Milan Crha
none Details | Review
proposed eds patch (774 bytes, patch)
2011-09-23 13:23 UTC, Milan Crha
rejected Details | Review
evo patch (3.14 KB, patch)
2012-04-23 09:44 UTC, Milan Crha
committed Details | Review

Description Christoph Wickert 2011-08-01 20:28:37 UTC
Description of problem:
The NetworkManager integration in evolution 3.0.x doesn't work.

Version-Release number of selected component (if applicable):
evolution-3.0.2-3.fc15.x86_64
evolution-NetworkManager-3.0.2-3.fc15.x86_64
NetworkManager-0.8.9997-5.git20110702.fc15.x86_64

How reproducible:
always

Steps to Reproduce:
1. Manually go to offline mode
2. Disconnect the network. 

Actual results:
A yellow error message box appears with „Evolution is currently offline due to a network outage. Evolution will return to online mode once a network connection is established.“, which is plain false. It was already offline and it was offline because I told it so. And it won't go online again automatically neither because it is offline.

When you go online again evolution still claims to be offline because the network was unreachable, so "will return to online mode once a network connection is established." is wrong in two ways.

Expected results:
From the moment the user tells evolution to go offline it should not care about
NetworkManager any longer. Basically what I 'd like to see is the behavior of the evolution 2.x series. It worked perfectly.

However the developers decided to go for huge notifications (see bug 653538) with error messages. Once you decide to have text there instead of just distinguishing offline and online, you also need to distinguish the reasons for being offline.

Online: No message
Offline due to NM: „Evolution is currently offline due to a network outage. Evolution will return to online mode once a network connection is established.
Offline due to manual disconnect: Completely ignore NM Status and display: 
„Evolution is currently offline. Click to work online again.
Comment 1 Milan Crha 2011-09-23 13:22:02 UTC
Created attachment 197353 [details] [review]
proposed evo patch

for evolution;

This changes behaviour close to that you requires. One thing is different, though, when you close evolution in forced offline state and then run it with no network connection, then you are notified about unavailable network, not about forced offline, because this forced offline doesn't make much sense when it's known that the network is not available. As soon as the network connection is established, evolution hides its note about network unavailability, but stays in offline, because that's what user asked for.

I also realized that evolution-data-server doesn't know about network outages, because evolution doesn't update /apps/evolution/shell/start_offline. It's sort of correct, thus I added a new GConf key /apps/evolution/shell/currently_offline, which is following EShell::online property, and then I changed EOfflineListener in eds to read the "start_offline" when it's created but listen to changes on currently_offline key. It seems to do the right thing for me now.

This cannot be added to 3.2.x, unfortunately, because of newly added strings in the schemas file.
Comment 2 Milan Crha 2011-09-23 13:23:19 UTC
Created attachment 197354 [details] [review]
proposed eds patch

for evolution-data-server;

Listen for currently_offline key in EOfflineListener.
Comment 3 Milan Crha 2012-04-23 09:16:45 UTC
The eds part is useless, I was told that eds cannot listen for this state from evolution, thus I'm obsoleting it. The evo part requires changes for 3.5.x (I missed 3.4.0 with this, I'm sorry), at least to move to GSettings from GConf.
Comment 4 Milan Crha 2012-04-23 09:44:27 UTC
Created attachment 212593 [details] [review]
evo patch

for evolution;

Updated patch, which uses GSettings instead of GConf.
Comment 5 Milan Crha 2012-04-23 09:46:40 UTC
Created commit bf2c718 in evo master (3.5.1+)
Comment 6 Milan Crha 2012-04-25 14:47:23 UTC
Hrm, the "currently-offline" option was not needed, due to removal of the eds part, which I didn't realize initially. I dropped it from the sources in commit 1a3913d, which is still 3.5.1+.
Comment 7 Fryderyk Dziarmagowski 2012-05-11 08:50:44 UTC
What about cherry picking it on gnome-3-4 branch?
Comment 8 Fryderyk Dziarmagowski 2012-05-11 09:10:00 UTC
It works partially form me. Now evolution comes back to the online mode, but when updating imap (google) accounts it hangs (POP3 seems to work) showing "Updating..."
Comment 9 Milan Crha 2012-05-11 12:07:40 UTC
(In reply to comment #7)
> What about cherry picking it on gnome-3-4 branch?

I thought of that, but I cannot do that, unfortunately, due to new strings added (3.4 is under string freeze).

(In reply to comment #8)
> It works partially form me. Now evolution comes back to the online mode, but
> when updating imap (google) accounts it hangs (POP3 seems to work) showing
> "Updating..."

I think you are facing other bug, the one about using stalled connections in providers. There are couple similar opened in bugzilla already.
Comment 10 Fryderyk Dziarmagowski 2012-05-11 13:15:10 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > It works partially form me. Now evolution comes back to the online mode, but
> > when updating imap (google) accounts it hangs (POP3 seems to work) showing
> > "Updating..."
> 
> I think you are facing other bug, the one about using stalled connections in
> providers. There are couple similar opened in bugzilla already.

I don't think so. Let's disconnect NM and connect it back and than click on a google imapx folder.
The result is an orange block containing a warning:

Error while Refreshing folder 'INBOX'. 
You must be working online to complete this operation