Can we put the weather data server URL into an easier configurable place? about libmateweather HOT 13 OPEN

Imagine the next time the new URL being longer than the old URL. Ad-hoc patching like what people are doing now won't work.

from libmateweather.

Ad-hoc patching seems not working for some people running older Linux distributions. If they don't get the patch from distribution repository at the end, they probably need to compile the library by themselves.

For where to put the URL information, those 3rd party URLs for example can be put into an extra text-format file in /usr/share/libmateweather, where currently only contains the location data in XML.

from libmateweather.

How is the average user going to know what the new weather service URL is?

What if the latest URL was stored in a file on github, and the app would occasionally pull the file down and store locally. If it can't find the file on github then use the URL in the local file.

from libmateweather.

That would be a great solution! It could be locally edited, but it could all happen automatically too..!

from libmateweather.

Ad-hoc patching seems not working for some people running older Linux distributions. If they don't get the patch from distribution repository at the end, they probably need to compile the library by themselves.

It was my case and even recompiling the library didn't work. My guess is that it is related to another linked library (libsoup) doing the request. I have sent a PR to resolve the issue: #131

from libmateweather.

I have patched my patch-hack to not include www. in the link, avoiding a 308 redirect which might be causing problems: patchmatelibweather

Your patch is wrong. The search pattern should include www., but the replace pattern not. See https://forums.linuxmint.com/viewtopic.php?p=2399362#p2399362

from libmateweather.

I guess this is the time to do it! Hopefully it will be easier for users to change the URL in case changes happen.

from libmateweather.

New releases for 1.26 and master branch https://github.com/mate-desktop/libmateweather/releases

from libmateweather.

Excellent idea to use a currently already used file location for storing the URL(s) in!

from libmateweather.

With libmateweather from current git master I had no trouble showing weather for a nearby airport in the US

from libmateweather.

I have patched my patch-hack to not include www. in the link, avoiding a 308 redirect which might be causing problems:
patchmatelibweather

from libmateweather.

Your patch is wrong. The search pattern should include www., but the replace pattern not.

Absolutely right, thanks, good catch. It seems I patched my patch way too hastily.
Corrected now.

from libmateweather.

How is the average user going to know what the new weather service URL is?

What if the latest URL was stored in a file on github, and the app would occasionally pull the file down and store locally. If it can't find the file on github then use the URL in the local file.

If the average user can not find a new weather service URL (by a google search for instance, or in this particular case through a server response code / redirect), he / she should:
a) get some professional help
b) wait "things to resolve by themselves" (by a package update, if he/she ia able at least to do that...)
I mean generally, for any computer issues.

Probably there wouldn't be /etc directory and/or dconf settings at all if such users would be a reference.

I think some simple way to change this URL (or any other setting that can change over night) would be a great addition, as one has a much more simple way to resolve even temporary changes. For such an average user, nothing would become more complicated though. Meaning a benefit for those who can use it, and no loss for the others.

Your proposal is just another exactly the same problem. Also a github file URL can change, so there would be a need to simply change that setting too. But how shall an average user know that... ;-)

from libmateweather.