With version 6.1-2, I was able to modify the cities file, in folder /usr/lib/budgie-desktop/plugins/budgie-weathershow and change one of the entries i.e. Oracle Junction US to Saddlebrooke AZ.
However, with version 6.2-20, If I do this same thing, the Applet displayed on the desktop always shows Apache Junction US.
I suspect you are not using the name in the cities file but using the Open Weather Map name. Any chance of changing this?
I am not sure what you mean, nor what is happening on your side. We are using the names in the cities file. The line in the file containing “Apache” reads: 5551535 Apache Junction, Arizona, US (now including state info, which we fetched via an web API, added to the file).
Editing is very possible btw, see my city:
The line Apache Junction US isn’t in the cities file at all, so I cannot explain how you get the mention.
What is the output of grep Apache /usr/lib/budgie-desktop/plugins/budgie-weathershow/cities ?
OK, tested on 19.04 using .8.0-0 on disco of weathershow Applet.
First off, with this version, there are a lot fewer cities, than the older versions For example, 5307464 Oracle Junction, Arizona, USA, that was in earlier versions, is no longer in this version.
So, I updated the cities file with 5307464 Saddlebrooke, Arizona, USA, log in/out. I then set the city in the applet configuration to Saddlebrooke, Arizona, USA. However, the display on the desktop shows Oracle Junction, US. Looks like the applet is using the 5307464 identifier and using the city from Open Weather Map.
Hi makitso,
There were several reasons to switch the file, among those were: the “old” citylist was based on a deprecated list (now impossible to even get) from OWM. That old list had many duplicates, or multiple stations for one city. Furthermore, the list had no state info.
What we are using is the “official” list to be used by app developers, extended with state info. OWM’s web interface uses other data which is not available for us.
It is really impossible that you get data, other than what is in the file, simply because I know the applet is not fetching citydata from the internet.
I can’t find saddlebrooke here https://openweathermap.org/city <-- that is the official web page for looking up weather areas
Wait, I think I know what you mean. The weather data json file includes the cityname that comes with the code. You can edit the name in the file cities, which will show in Settings, but the cityname on the desktop is from the json file, fetched by the code.
Bingo. Can you use the name from the cities file, like it was in 6.1-2 instead of the json file?
Currently no, that would take a code change. I believe it was always like this btw, but I need to check. The old one was python.
@fossfreedom – your absolutely correct, that city is not in Openweathermap.org/city.
But, the goal here was to change the local desktop name of an existing city in the city file to saddlebrooke. In reality, Saddlebrooke is about 3 miles from Oracle Junction. This whole thing was for cosmetics only.
Another point. The cities file for the latest .8.0-0 version is missing some cities that are on the cities file from Openweathermap.org. IHMO, looks like someone arbitrarily deleted some – including Oracle Junction.
You wouldn’t want the (sometimes long) names as a general rule btw:
Washington, D. C., District of Columbia, US
True, some cities are missing, but as said, the web interface list is simply not available to us. Most of the missing entries were exhaustive translations of the same city though.
For the most part, I am doing this for the learning experience and partly personal use (I really want to learn Vala), but I made this change to use custom cities if it’s of any use / interest.
:Certainly interested what code changes you have made.
The key is stability. We have spent many sleepless nights making the weather applet absolutely stable. Basically never assume in the code that anything processed is the right format.
So in this case probably checking that strings cannot be null or empty / cannot be too long / doesn’t contain any strange characters that would break formatting e.g. /r /t /n etc. Checking it handles unicode characters carefully e.g. caret umlauts etc. Always assume the user entering stuff via the front end or the backend is the bad guy trying to break stuff.
I posted here:
Few things:
I tried to follow what was already there and make my changes using the same conventions and methods already there as best I could.
Probably should have more checks for null/empty strings. I changed it to not allow them to be displayed, but maybe more checks are needed, and the default in the schema should probably not be an empty string either.
I was planning on setting a max length to the entry box. As is, you can use a really long name, and it will change the box to be really long on the desktop, noticeable when transparency is not 100%. If you then set a smaller name (or turn off the custom name), the box stays long until you logout/in.
I tried breaking it with special characters, haven’t been able to yet, but maybe more checks are needed there. For example, it works with many like these, which I am not sure if it is good or bad:
many thanks - please can you do a pull request?
merged. This will be in tomorrows daily ppa build and 20.10
