| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
While doing testing I noticed that skeletons were being leaked, and
eventually tracked it down to the timer that updates the time label
closing over "this" and then keeping the reference alive, potentially
for 24 hours.
I noticed a few other places in the code doing some version of this, and
one of them had the "static and weak pointer" approach, which I pulled
out into a util class. Now, we still have to make sure we're passing it
a static method instead of a lambda, as that would also close over
"this" and render the whole thing useless, but at least most of the
annoying parts live in the util class now.
Also the call_widget version was doing a weird thing where it was
removing itself, but then returning "true"? I'm not sure what that
accomplishes, because returning "false" means to not run this again. So
I think my new version is the same in practice, but simpler...
There are other timeouts in the code that I briefly looked over, but all
of them seemed to be relatively short hard-coded durations, so I left
them alone.
But if any of them are long-lived, it's possible they could also benefit
from this class in the future.
Closes #1480
Co-Authored-By: Marvin W <git@larma.de>
|
|
|
|
See https://gitlab.gnome.org/GNOME/vala/-/issues/1474 and https://gitlab.gnome.org/GNOME/vala/-/issues/1478
|
|
Basic configuration of qlite, xmpp-vala, the Dino library and the Dino
application are supported. There's no support for the plugins.
This e.g. enables using the Vala language server.
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Marvin W <git@larma.de>
|
|
|
|
fixes #707
|
|
|
|
|
|
|
|
|
|
|
|
This is still disabled by default until prioritization is implemented;
otherwise this could be preferred to HTTP uploads.
File sending only works via Jingle In-Band-Bytestreams right now, more
transports are going to be implemented.
To test this, uncomment the line with `JingleFileTransfer` in
libdino/src/application.vala.
|
|
|
|
Message search
|
|
|
|
|
|
|
|
|
|
libdino/NotificationEvents
|
|
|
|
* 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- add install and uninstall targets
- compatibility for systems without pkg-config
|
|
|
|
|
|
|
|
|
|
|
|
Also make OpenPGP code use this API
|
|
|
