Bug 1105

(In reply to comment #0)
> Also, there should be an option in most of the apps that will make them watch
> for an available connection and do their sync'ing/connecting/etc. when the
> network is available, instead of an option that makes them do their stuff "on
> startup".

Another way to do this is to put "Connect on application startup", then have a check box underneath (grayed out if "Connect on startup" is unchecked) that say "Wait for network if necessary".

Konversation has this too. I'd like it to just automagically  go online when my connection is up

Calvin

(In reply to comment #2)
> Konversation has this too. I'd like it to just automagically  go online when my
> connection is up

It doesn't have it, but it should :-)

Is a check box for "Wait for network if necessary" needed?

The detection should be quiet and smart. For example, in KMail, when "Check mail on startup" is enabled (Accounts -> Receiving), KMail (and any other app) should check for a network connection and when not available just sit there and be quiet. Associated notification popups should be disabled automatically.

For apps with associated system tray icons the icon could have an additional status indicator.

Repeat the same act when KMail interval checking is enabled for each email account. When the network is available fetch mail and when not available just be quiet.

Possibly a stdout/stderr message could be generated, but the message should be informative and not alarming. For example:

[kmail] Network unavailable. Not checking mail.

[korganizer] Network unavailable. Not updating calendar.

[konversation] Network unavailable. Not connecting.

The backend stuff has been added to enable our apps to receive signals when the network goes up or down. I didn't look through the git or mailing list. I have it in my mail archives:


[quote]

TDEGlobalNetworkManager* nm = KGlobal::networkManager();
if (!(nm->backendStatus() &
TDENetworkGlobalManagerFlags::BackendUnavailable)) {
  // A network management backend is available
  connect(nm,
SIGNAL(networkConnectionStateChanged(TDENetworkGlobalManagerFlags::TDENetworkGlobalManagerFlags,
TDENetworkGlobalManagerFlags::TDENetworkGlobalManagerFlags)), this,
SLOT(theGlobalNetworkStateChanged(TDENetworkGlobalManagerFlags::TDENetworkGlobalManagerFlags,
TDENetworkGlobalManagerFlags::TDENetworkGlobalManagerFlags)));
}

I could definitely use some assistance in updating konversation/kmail/etc
to incorporate this new functionality, so if you want to hack on those
applications please feel free!
[/quote]

Is that code for the network-manager app or generic network detection code? Why not just query ifconfig? I don't know --- I'm asking.

This is example code that should work with the R14 network backend for trinity.

If the code is only backend support then sounds like that would work for detecting the network directly within Trinity rather than externally through something like ifconfig.

I raise the topic because to resolve this bug report, users who don't use the Trinity network manager need a direct way to detect the network.

I'm not a C++ coder, but if the backend is creating a slot then seems a signal would return the network result. At that point, seems only an if control is needed. For example, with KMail,

if Backend is Available
  Check mail on startup;
else
  fprintf (stderr, ""Network unavailable. Not checking mail.\n");

if Backend is Available
  {
  if check interval period is >= user's config
    check mail;
  }
else
  fprintf (stderr, ""Network unavailable. Not checking mail.\n");

Well, something like that. :)

(In reply to comment #8)
> If the code is only backend support then sounds like that would work for
> detecting the network directly within Trinity rather than externally through
> something like ifconfig.

Correct.  The preferred method to detect network access is to query the TDE network manager as quoted by Calvin above; if a suitable network backend is unavailable TDE will simply report that the network is available regardless of physical hardware status.

All low level functions (for example querying ifconfig) should NOT be placed into high level applications such as kmail; instead, if the network-manager backend is unsuitable for some odd reason a simple ifconfig backend could be written for the TDE network manager.  That, however, is beyond the scope of this particular bug report. :-)

That's fine. My only point is that no packages other than basic Trinity libs should be required to detect the network availability. I only wanted to ensure people don't have to install other packages such as network-manager to resolve this report. :)

(In reply to comment #10)
> That's fine. My only point is that no packages other than basic Trinity libs
> should be required to detect the network availability. I only wanted to ensure
> people don't have to install other packages such as network-manager to resolve
> this report. :)

I see your point.  This report can be indeed be resolved via the TDE network manager without relying on any other packages.

(In reply to comment #11)
> (In reply to comment #10)
> > That's fine. My only point is that no packages other than basic Trinity libs
> > should be required to detect the network availability. I only wanted to ensure
> > people don't have to install other packages such as network-manager to resolve
> > this report. :)
> 
> I see your point.  This report can be indeed be resolved via the TDE network
> manager without relying on any other packages.

Except not everyone will want to use the TDE network manager, for example if they already have something else configured to manage their networks, e.g. wpa_supplicant, wicd, etc. I'm in agreement with Darrell on having a way of detecting the network available in the base libs, without having to rely on any one particular network manager.

Notes from a dev mail list discussion:

Not everyone uses a wireless connection. Some people use hard-wired connections --- and we must remember modem users. Thus a more fundamental approach is needed rather than depend upon NetworkManager.

One idea is to implement as a KDED service, pinging to a configurable gateway IP address to expose the network state via DCOP. All Trinity network-ready apps would check with the service before attempting online connections.

The method used must be transparent and fault tolerant. That is, if implemented as a KDED service and the user disables that service, then everything keeps working as is currently coded.

For example, if the service is disabled and a user starts kmail but the user's local gateway/router is offline, then kmail would show the kdialog failures for connecting to accounts. If the service is enabled and the user starts kmail with the local gateway/router offline, there would be no kdialogs because kmail does not try to connect to any accounts.

The local gateway IP address should be user-configurable. An example is my own connection. My computers connect to a local router, which is behind a VOIP router, which is behind the ISP's CPE device, which is behind an ISP access point (this is a proprietary wireless broadband system). There are also the local ISP DNS servers. I could configure any of those IP addresses as a test.

(In reply to Darrell from comment #13)
> Notes from a dev mail list discussion:
> 
> Not everyone uses a wireless connection. Some people use hard-wired
> connections --- and we must remember modem users. Thus a more fundamental
> approach is needed rather than depend upon NetworkManager.
> 
> One idea is to implement as a KDED service, pinging to a configurable
> gateway IP address to expose the network state via DCOP. All Trinity
> network-ready apps would check with the service before attempting online
> connections.

Another option is to check if a network manager is exposed via dbus or DCOP (e.g. wpa_supplicant, network-manager, etc.), and provide ping as another (backup?) option.

> The method used must be transparent and fault tolerant. That is, if
> implemented as a KDED service and the user disables that service, then
> everything keeps working as is currently coded.
> 
> For example, if the service is disabled and a user starts kmail but the
> user's local gateway/router is offline, then kmail would show the kdialog
> failures for connecting to accounts. If the service is enabled and the user
> starts kmail with the local gateway/router offline, there would be no
> kdialogs because kmail does not try to connect to any accounts.
<snip>

If no connection is available, I'd suggest a dialog saying something to the effect of "No network connection is available. <insert function here> will be performed when a connection is established." with a check box saying something like "Do not show this message again." That way, if the user is unaware that she/he has been disconnected, she/he can take the necessary action to reconnect, or simply ignore the message.

Basic support for online/offline detection was added to KMail in GIT hash 111cc21 (tdepim).

This new code uses the TDE network management system to detect online/offline status; if network-manager is not available it will assume you are online.  This can be changed easily in the future by adding a new backend to the extensible TDE network management system that queries online status directly instead of going through network-manager.

Right now there is no GUI-based notification as discussed.  The patch above provides an initial starting point from which we can develop this feature more fully, then replicate the solution to other TDE applications.

>Basic support for online/offline detection was added to KMail in GIT hash 111cc21 (tdepim).
>This new code uses the TDE network management system to detect online/offline status;

Can there be a way to disable this behavior?
(or, better, make it aware of other connections configured outside networkmanager, as suggested in previous comments - if nothing else, tdenetworkmanager could be aware there's a network connection available and not pretend the whole machine is offline when it's not, when other programs rely on this information)

Also related to the topic:
In my case, KMail doesn't like to use cached data, and displays "Offline KMail is currently in offline mode. Click here to go online ..." It should use the cache.

And a small bug:
When I click "here" to turn KMail online, I expect it to load and display the content of the directory it doesn't show from cache. Currently, I have to click somewhere else and return to the directory I wanted to see in the beginning.