This fixes a few issues, and removes some broken providers.

Mostly some unused licenses.

Markus Göllnitz (b9a2126c) at 19 Nov 04:30

Markus Göllnitz (6f3c1d4b) at 19 Nov 04:29

Journey reloading used to live in the details page instead of in the journeys themselves. Moving it to the more sensible location being the journeys, however, led to the details page not setting the new journey, but instead the journey being updated.

This broke with the details page's assumption that a journey update corresponds with updating the journey property.

Because journeys are not immutable, introducing a new signal to them signalling an update is a proper solution for this issue.

Markus Göllnitz (cdebe4a3) at 19 Nov 04:27

Markus Göllnitz (a6d3a203) at 19 Nov 04:26

Interesting idea! Let me try to explain, why I don't think Railway will gain this feature anytime soon, and what it would take outside of Railway to make it happen.

First, why don't we just do the same as Mobian's gnome-clocks?

Mobian's patches are in an open MR to Clocks, on which I commented before that it will not work with Flatpak: https://gitlab.gnome.org/GNOME/gnome-clocks/-/merge_requests/344#note_2491492 A dedicated timer portal or similar have been in the talks for quite some time, but never materialised.

Downstreams can ship workarounds, of course, as shortcuts. (Some do it more often, especially the commercial ones.) Regardless, I don't think anything shy of such a portal will support us in the long run.

Especially for Railway, the ability to ship new versions quickly independent of the system through Flathub is extremely helpful, as the recent DB API breakage shows. So, I would not like to see a feature implementation that does not work with Flatpak.

Second, why don't we talk to Clocks?

Besides the fact, that Clocks does not provide such API (nor am I convinced it would be the right thing for it to do so), there are practical issues with that suggestion with regard to suspend:

Clocks will wake up the system shortly before its alarm will go off. You want Railway to check for any potential delays. Railway might have not done so for quite a while, because it does not wake the system itself – snoozing-style as done by Android and other always on capable OSes. Thus, the alarm will probably go off already, only then to be corrected.

And if you are after delays you also might want Railway to wake you up immediately when connections become impossible due to delays, right? For that, you definitely need such snoozing and Clocks is no help at all.

This again suggests we need a proper system service with a portal and not a direct connection to Clocks.

Markus Göllnitz (3e9812a3) at 02 Nov 04:29

... and 1 more commit

Without this, if the background timer ran on a journey that was already in the past, the timer duration was determined to be 0 resulting in an infinite loop taking potentially a whole CPU thread.

Annoyingly, this timer is triggered before the main window opens, if a journey was kept in the journey store which is over, e.g. with delete-old = False or if the journey ended shortly, within the deletion-time period.

Thus, this can even lead to Railway never starting.

Markus Göllnitz (d1f1caed) at 02 Nov 04:27

... and 1 more commit

This spacing resulted in weird looking padding between the scrolled window and the banner with the scrolling undershoot shadow floating these 12 px below the event.