aboutsummaryrefslogtreecommitdiff
path: root/libdino/src/service/connection_manager.vala
Commit message (Collapse)AuthorAgeFilesLines
* Fix runtime criticalsfiaxh2018-09-161-8/+14
|
* Initial implementation of SCRAM-SHA-1Marvin W2018-09-011-1/+1
|
* Small connection fixesfiaxh2018-03-101-41/+35
|
* Move Jid class to xmpp-vala, partially refactor namespaceMarvin W2018-01-281-13/+13
|
* Move to GNetworkMonitor (#236)Mathieu Bridon2018-01-091-20/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Move to GNetworkMonitor Dino currently talks to NetworkManager over DBus to know the state of the network. That doesn't work in a Flatpak sandbox by default though, because Flatpak filters DBus communications and only allows a very small set of things to pass (which are known to be safe). Gio provides an API to know the state of the network (and be notified of changes via a signal): GNetworkMonitor. And GNetworkMonitor works both inside a Flatpak sandbox, and in traditional builds. (in Flatpak it uses what we call a "portal", which are the clean, safe way to let apps exit their sandbox) Fixes #235 * Don't check for network connectivity for now The connectivity check really is the correct thing to do: * network_available means that the computer has network routes to "somewhere". That is, it is connected to a router. * connectivity.FULL means that the computer can access "the Internet". That is, if it is behind a router, that router is connected. As a result, only checking for network_available is not correct. Unfortunately, NetworkManager tends to wait a long time before checking for connectivity. As a result, it is possible that a transient network error leaves NetworkManager thinking that network_available is true but connectivity!=FULL, and it will wait several minutes before realizing that the Internet connexion did come back. During that time, apps checking for connectivity (e.g the whole GNOME desktop) will think they don't have access to the Internet, while apps that don't (e.g Firefox) will access the Internet just fine. Users are understandably confused when that happens. Removing the check for connectivity is an acceptable trade-off in the short-term, until this situation is improved on the NetworkManager side. https://bugzilla.gnome.org/show_bug.cgi?id=792240
* Show error on invalid TLS certificatefiaxh2018-01-041-12/+24
|
* Read+(write) stream asyncfiaxh2017-11-161-32/+19
|
* Replace deprecated function usagesfiaxh2017-11-161-3/+1
|
* Go offline before quiting applicationfiaxh2017-10-311-5/+20
| | | | fixes #141
* Fix warningsfiaxh2017-10-311-1/+0
|
* Remove new from struct initialisation, as it is deprecated (#180)linkmauve2017-10-231-2/+2
| | | | | | * Remove new from struct initialisation, as it is deprecated. * Use Map.has_key instead of Map.contains, as it is deprecated.
* http-files: max-file-size handlingfiaxh2017-09-261-1/+1
|
* Use utc time everywherefiaxh2017-08-311-1/+1
|
* connection: keep-alive pings, act upon connection change (VPN)fiaxh2017-08-251-7/+47
|
* Stream Managementfiaxh2017-08-141-1/+1
|
* Get rid of manual storage objects for delegatesfiaxh2017-06-131-19/+8
|
* Show account status (incl errors) in ManageAccounts.Dialogfiaxh2017-04-101-41/+88
|
* Add --print-xmpp flag to log detailsMarvin W2017-04-031-1/+2
|
* Add typed identity to manager modules and stream flagsfiaxh2017-03-201-1/+1
|
* Fix account repeated disconnect/connect issuesMarvin W2017-03-131-4/+7
|
* Use typed identity in stream modulesfiaxh2017-03-111-2/+2
|
* Initial plugin systemMarvin W2017-03-101-0/+222