GitLab

It's not used here anymore.

Make clear to the user that there are two different types of data,
as stated on http://api.yr.no/faq.html#times, and get rid of the
confusing terms "point data" and "interval data".

http://api.yr.no/license_data.html states:

Credit should be given to The Norwegian Meteorological institute,
shortened met.no as the source of data with use of our logo.
The logo should be followed by a text. Some suggestions:
"Data from The Norwegian Meteorological Institute",
"Based on data from Norwegian Meteorological Institute".
You can find our logo here: http://met.no/Om_oss/Logo_til_metno/.

Unfortunately, the link to the logo is dead, so let's fetch it
from the met.no website (http://met.no/filestore/met.no-logo.gif).

Do not mix up the terms low/medium/high clouds with "cloudiness",
even if they are given in percent ;-)

Since the forecast data is requested using latitude and longitude,
we're free to set the location name to something arbitrary. As a
first step, sanitize the location name returned by the search
dialog or by auto-detection via IP address and remove the code added
previously for keeping an extra short location name.

Relying on the automatic gtk widget size management, I was terribly
unsuccessful producing a nice result. So in a new attempt, let's
try to do the problematic stuff manually:

* Use a fixed size of 150px for the forecast boxes.
  That makes the table look a bit more homogenous.

* Use a fixed width for the scrolled window:
  - 650 pixel for monitor width <= 720
  - 700 pixel for anything bigger

* Stuff the scrolled window into an event box to make it look more
  consistent with the scroll-less version.

Because of the fixed width, some labels in the forecast boxes can
now be cut off. If that's the case, we'll need to tweak/enlarge
the forecast box width, it can't be that much off. I hope the
current setting works for most translations, though.

Optimize calculation introduced in b5d407d7.

Fix some memory leaks related to translations in summary and
to the creation of current conditions.

gtk_widget_show_all() is called on the parent container, making
these calls obsolete.

Left-over from b1eeec78.

This should make both users of small and big screens happy.
Successfully tested with resolutions from 640x480 to 1920x1080,
bigger resolutions will very likely cause less trouble.

While it is a bit of a compromise and there's certainly room
for improvement (anyone wants to volunteer?), it works fine in
most cases.

Add a spinner button to the configuration dialog and read/write
config entries. The max limit is 10 days, as imposed by the XML
feed.

We're switching between systems of units, make this description
more clear and exact.

Rename all variables and texts accordingly.

Now that we're dealing with combined instead of simple timeslices,
make these changes evident by renaming the variables to something
more reminiscent of "weather".

Instead of recreating the current conditions again and again on
different occasions, make them once on update and save it in
xml_weather->current_conditions. This should be a bit more
consistent too.

Enhance xml_time with an extra field holding the time of
point data. While this provides extra info for the user, its main
intention is for making debugging a bit easier, in case something
goes wrong or the data provided changes in a way we did not
expect.

Also, we do not mix up times of point and interval data in the
forecast anymore, which was only a transitional solution.

In the forecast details tab, we can now present the times for
both point and interval data. While doing so, add a short
explanation what these times are about.

We're always providing combined point and interval data, so there's
no need for the interval parameter.

get_data() will be the place to handle conversions from metric to
imperial and vice-versa. Prepare this by adding units as a parameter
similar to get_unit() and changing all function calls appropriately.

Format start and end time according to the user's locale setting.

Values like temperature, wind speed etc. are returned as immutable
strings. That's bad because those values are not printed in the
format defined by the user's locale.

As a first step, duplicate the strings in get_data() and free them
in the calling functions. Remove usage of CHK_NULL from get_unit(),
as it would create a memory leak.

When the location name is too big it causes the summary window
to grow, making the layout look awful. So for the subtitle, shorten
the location name and only use the name of the city.

We might want to use the shortened name elsewhere, and maybe
let the user change it, so let's serialize it.

Thanks to Algimantas Margevičius for reporting this.

Make the precomputed overall cloudiness available in the current
weather display and the forecast summary.

Add altitude, latitude and longitude from the XML feed.
We may already know latitude and longitude from the location the
user selected, but it might be a bit different in the XML document.

Make the weather forecast tab work again!

Instead of presenting an empty window, show instructions when
no location has been set, or a message when no data is available.