Bug 263626 - Does not try to get online when it should after explicit user actions.
Summary: Does not try to get online when it should after explicit user actions.
Alias: None
Product: KDE PIM Mobile
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Windows CE Microsoft Windows CE
: NOR minor
Target Milestone: ---
Assignee: kdepim bugs
Depends on:
Reported: 2011-01-19 10:31 UTC by Bernhard E. Reiter
Modified: 2018-09-04 20:02 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard E. Reiter 2011-01-19 10:31:30 UTC
There are number of situation when Kontact Touch should try to get online,
but does not. In the case where the user explicitely triggers an action
that requires online status, it should be attempted and there should be feedback if it does not work out.

For all situations holds: If the user has choosen to be in offline mode,
he should get asked if he wants to stay in there or switch to online mode.

a) Menu entry: sending all queued emails via the start level menu.
b) Menu entry: sync this folder
c) Menu entry: sync all accounts
d) Sending an email by closing a composer
e) sending and email by changing an appointment or task with attendees

windows-ce/Kontact-Mobile/testing/2011-01-17-02-23/ does not go online

There are weaker conditions when a sync should be attempted (especially if a device could in principle go online):
i) startup of the application backend (e.g. for checking the sieve script situation)
ii) startup of one of the frontends
iii) selection of a folder or a favorite group with the setting sync on selection

Maybe feedback can be different here. I feel like no immedeate 
failure notice is notified for instance.
Comment 1 Bernhard E. Reiter 2011-01-19 10:44:42 UTC
f) explicite change from offline to online.

I wanted to write that windows-ce/Kontact-Mobile/testing/2011-01-17-02-23/
does not go online for the explicit actions I've tested.

Workaround to continue working as far as I know is to switch offline,
go online by the webbrowser or diffently outside Kontact Touch
and then switch online.
Comment 2 Andre Heinecke 2011-01-20 17:27:55 UTC
If this is WinCE only it could be fixed in:
SVN commit 1215969

Before that commit establishConnection did not work after a connection loss.
Comment 3 Bernhard E. Reiter 2011-01-21 09:35:33 UTC
I haven't tested this on N900. If you need a test there, get someone to do this test. :)
Comment 4 Andre Heinecke 2011-01-21 18:49:40 UTC
SVN commit 1216169 by aheinecke:

- Remove the use of private qt api. This did not work as intended
  so the status was never updated. When there was no instance of
  networkingcontrolmgr. (The minimalnetworkingclient used to test
  before does that)
- Instanciate WinCE Networking Control Manager because it handles
  the Window Messages notifing about a Network status change.
- Create the Networking control manager as a child window
  of the correct qt main window. So Messages are recive correctly
  even in multithreaded applications with multiple windows.
- Cleanup debug output a bit.

CCBUG: 258271
CCBUG: 263626
BUG: 263131

 M  +12 -23    networking_wince.cpp  
 M  +4 -0      networking_wince_p.h  
 M  +43 -7     networkingcontrolmanager_wince.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1216169
Comment 5 Volker Krause 2011-01-24 11:30:50 UTC
Does this still happen after Andre's changes on WinCE?
Comment 6 Andre Heinecke 2011-01-26 10:33:45 UTC
Now that the status is correctly reported at least work online/offline triggers going online. According to Volker sending mails should also try to go online now still waitingforinfo because we might find additional spots where a connection should be established.
Comment 7 Andre Heinecke 2011-02-15 16:11:04 UTC
Moved down to minor since the most explicit actions now work.
Comment 8 Andrew Crouthamel 2018-09-04 20:02:06 UTC
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I will be closing this bug.