The original version used conditions as key. This does
not work out for all providers. They might return no
value while gweather derives icons from other fields.
This commit introduces two new classes:
1. GCalWeatherService
2. GCalWeatherInfo
GcalWeatherservice picks-up the current location and periodically
fetches weather reports represented by GcalWeatherInfo.
The weather part is not complete yet.
Currently we split a URI string with a Regex which is error prone. As
libsoup already provides a facility to parse a URI into its parts
we should use this instead. Therefore our utility method is not necessary anymore.
Follow https://wiki.gnome.org/HowDoI/SaveWindowState
* Use tuples in gsetting schema to save size and position
* Save changes to variable instead of saving to gsettings after every timemout
* Save the changes back to gsettings when the window is finalized.
The old code here was not setting tzid correctly. It me took hours to
figure out how to do this, but it turned out to be simple once I found
the right place, buried deep in the e-d-s source code.
Now, ideally we would not change the timezone of the event every time we
edit it. But some big changes in how GNOME Calendar tracks timezone are
going to be required if we do that. In particular, I believe we would
have to stop saving all day events in UTC, and give up on using
GDateTime as we do now, and track timezone completely separately
everywhere using icaltimezone. This is what e-d-s does, and it's
probably what we should be doing too. But that would be a big change.
This commit solves the basic problem, which is to ensure the event is
scheduled for the right time, regardless of timezone.
This finally completely fixes#168.
This reverts commit ce2c955269.
This commit is not right. Lots of code in Calendar relies on being able
to set the timezone of a GcalEvent, and this results in us always
ignoring the timezone set by Calendar in preference to whatever happened
to be in the ECalComponentDateTime previously. That might not be so bad,
but additionally, the time is not adjusted accordingly, so this actually
results in the time of events changing unexpectedly from what Calendar
is trying to set.
The code to explicitly store UTC times for all day events is OK (I
guess) and will be restored in a subsequent commit.
g_date_time_equal() corrects for timezone offsets to ensure that, e.g.,
6 AM CST is treated as equal to 12 PM UTC. This means attempts to change
the start and end times of events to the same time in another timezone
are currently failing. We need to remove this attempt at optimization
because it prevents gcal_event_set_timezone() from ever doing anything.
The tooltips think all events start and end between 1:00 and 1:59,
because we are missing a % in the format string and the I looks like 1.
I like it when bugs turn out to be easy. Fixes#225.
In month view, when clicking on a day of the month, every event is
initially an All Day event until the user opens the Edit Details dialog
and unchecks the checkbox. This means that the event is originally
created in UTC time, and needs to be explicitly switched to local time.
Florian Brosch