weather app for the terminal

This is a followup to discussion on Alacritty commit 3ad68699 (Alacritty is a "cross-platform, GPU-accelerated terminal emulator").

The problem is that, in some terminals, wego 2.0 table alignment suffers from the width of the unicode characters used (cloud, sun, etc). See for yourself:

• GNOME Terminal:
  
• Alacritty:
  

To me that looked like a bug in Alacritty, but its main developer, @jwilm, comments that:

I believe this is a bug with wego. They don't account that terminals may display a cloud as 1 or 2 columns. GNOME Terminal appears to think the cloud icons are only single width. Alacritty (correctly) handles them as double width. We are using the Unicode 9 definitions for wide chars, so that may account for the difference.

In the wego emoji frontend,

ret = append(ret, fmt.Sprintf("%v %v %v", cur[1], icon[0], c.formatTemp(cond)))

you can see that there's a space after the icon in the Sprintf format string. It's not visible in GNOME Terminal because it's under the emoji. You can see it in Alacritty because we account for the double width characters.

wego should be using the goto functionality of terminals to handle both cases.

You should really add to README under dependencies that ingo needs to be installed since it says nowhere that you must install ingo prior to installing wego:

Install ingo prior to installing wego go get -u github.com/schachmat/ingo

You also may want to clue users in to how to install go also (prior to installing ingo obviously):

Mac OS X install of go using homebrew brew install go

The readme is really confusing and results in a nasty error message and no clues in the error message that the reason it's not working is because ingo wasn't installed prior to installing wego...also when you run wego on first run without ingo installed it says nothing about the configuration file not being automatically generated and nothing about ingo not being installed so it's super confusing...should probably add a check on execute of wego that verifies ingo is installed.

2015/06/01 09:27:47 Get https://api.worldweatheronline.com/free/v2/weather.ashx?key=144cf08839d70a63db650f9750bb9&q=Zurich&format=json&num_of_days=3&tp=3&lang=de: x509: certificate signed by unknown authority (possibly because of "x509: cannot verify signature: algorithm unimplemented" while trying to verify candidate authority certificate "COMODO RSA Certification Authority")

Maybe adding 'x509 Certificate issue' will solve it?

Hello,

I'm trying to launch wego under ubuntu 14.04 x64, but it fails each time I try to launch it with the following error:

$ ~/.gocode/bin/wego 
unexpected fault address 0x7f5000000011
fatal error: fault
[signal 0xb code=0x1 addr=0x7f5000000011]

goroutine 3 [running]:

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

    :0

goroutine 1 [select]:
main.main
    /home/artemz/.gocode/src/github.com/schachmat/wego/we.go:441

Hi,

sorry I didn't necessarily wanted to open an issue for it but my ascii art looks a bit weird. At least it does not look the way it looks in the screenshot of your installation instructions. Does it only work with specific fonts? I can't really see the clouds its just some slashes and dots. Same with the sun.

thanks in advance kevin

The standard location for config files is not $HOME but $XDG_CONFIG_HOME, which default to $HOME/.config/.

More info:

• https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
• https://wiki.archlinux.org/index.php/XDG_Base_Directory_support

You will find plenty of projects have moved their config files to $XDG_CONFIG_HOME to comply with this standard. I think wego should do the same and move the config to something like $XDG_CONFIG_HOME/wego/wegorc.

Beyond standard compliance, this helps a lot users who want to sync config files between several computers. Instead of having files scattered all over $HOME, they are all tidy and neat in one place.

I pushed the first version of the forecast.io backend to the forecast.io branch. Some points need to be adressed before merging into master:

• [x] double-check to implement the maximum possible of the iface in condition
• [x] min- and max-temperature for daily data
• [x] astronomy for daily data
• [x] remove debugging code and commented out code
• [x] restrict return value of Fetch to the requested number of days
• [x] add language flag
• [x] add call to time machine api to get "forecast" for the passed time of the current day
• [ ] (optional) is there a better possibility to specify location other than a lat,lon string?

So far, you use wego 1 Paris to fetch weather data for Paris for 1 day. With this commit, you use wego -days 1 -city Paris to fetch the same information. Benefit of this approach is that (1) it prints help message when you do wego -h (2) it is clear what data you're seeking.

PS - I really loved wego. And I am learning golang. So I felt like adding this simple support for flags as a part of learning and contributing back to wego. :smiley:

$ wego
2015/05/17 22:32:30 Get https://api.worldweatheronline.com/free/v2/weather.ashx?q=New+York&format=json&num_of_days=3&tp=3&lang=de: dial tcp 37.220.91.249:443: network is unreachable

A number of countries in Europe use meters per second for wind speeds, rather than kilometers per hour. Would it be possible to have another wind speed option that could display wind speeds in m/s? This appears to already be an option available on darksky.net.

I added these two changes to my fork of wego so I could get letters instead of the arrow icons for wind direction. Please add these changes if they're a good fit.

Thanks for wego!

Related with https://github.com/schachmat/wego/issues/116

os.UserConfigDir() docs:

On Unix systems, it returns $XDG_CONFIG_HOME as specified by https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html if non-empty, else $HOME/.config. On Darwin, it returns $HOME/Library/Application Support. On Windows, it returns %AppData%. On Plan 9, it returns $home/lib.

Currently .wegorc defaults to $HOME/.wegorc in all systems. I'm proposing this logic for searching/creating the config file:

1. $WEGORC takes the highest precedence.
2. If $WEGORC is not set, try to open the config file from os.UserConfigDir()/wego/wegorc (can adjust the name, but the point is it is stored inside os.UserConfigDir)
3. If the config file is not found, fallback try to open the config file from $HOME/.wegorc for backward compatibility
4. If still now found, generate the config file
   • in $WEGORC if it is set
   • else, generate the file in os.UserConfigDir()/wego/wegorc

This adds a basic markdown output formatter. Based on the ascii art formatter, with the icons from the emoji formatter.

Sample output from go run main.go -u imperial -l 27312 -d 1

Weather for Pittsboro, US

scattered clouds ☁️ 95 (97) °F

Forecast for Wed Aug 03

| Morning | Noon | Evening | Night | | ------------------------- | ------------------------- | ------------------------- | ------------------------- | | clear sky | scattered clouds | scattered clouds | scattered clouds | | ☀️ 80 (80) °F | ☁️ 95 (97) °F | ☁️ 95 (97) °F | ☁️ 95 (97) °F |

Trying to get WeGo on Windows 10....So far, I have installed NixOS and WSL2 via Powershell and when I run:

go get -u github.com/schachmat/wego export PATH=~/go/bin:$PATH wego

I get "Could not find selected backend forecast.io" after "wego" tries to execute. Please help.

• Make sun in "partly cloudy" less irregular

• Make "sunny" more intense

  I have noticed that when there's a lot of "sunny" and "partly cloudy" in the output, it's not apparent at first sight which is which. This should make the "sunny" icon more intensely yellow, and therefore more discernible.

• Make dark grey and dark blue a bit ligther

  Previous colors were not readable against some background colors, e.g. #0a3947. New colors are more readable but should be still sufficiently darker than the ones used for light clouds (250) and light rain (111).

Here's a screenshot of the "too dark" problem on my terminal:

Feel free to pick just some changes if you don't like one of the others.

As I dig more into data returned by OpenWeatherMap, it looks like multiple fields (visibility,sunset,sunrise) are not output correctly by json frontend of wego.

Here's an example of data returned by OpenWeatherMap:

{
  2   "cod": "200",
  3   "message": 0,
  4   "cnt": 40,
  5   "list": [
  6     {
  7       "dt": 1611468000,
  8       "main": {
  9         "temp": 9.02,
 10         "feels_like": 6.94,
 11         "temp_min": 9.02,
 12         "temp_max": 9.74,                                                                                                                
 13         "pressure": 1014,
 14         "sea_level": 1014,
 15         "grnd_level": 1012,
 16         "humidity": 80,
 17         "temp_kf": -0.72
 18       },
 19       "weather": [
 20         {
 21           "id": 800,
 22           "main": "Clear",
 23           "description": "clear sky",
 24           "icon": "01n"
 25         }
 26       ],
 27       "clouds": {
 28         "all": 1
 29       },
 30       "wind": {
 31         "speed": 1.59,
 32         "deg": 290
 33       },
 34       "visibility": 10000,  // <-- Visibility  Visibility  Visibility  Visibility  Visibility  Visibility 
 35       "pop": 0,
 36       "sys": {
 37         "pod": "n"
 38       },
 39       "dt_txt": "2021-01-24 06:00:00"
 40     },
 41     {
 42       ...
 43     },
 44     .
 45     .
 46     .
 47   ]
 48   "city": {
 49     "id": 5391959,
 50     "name": "San Francisco",
 51     "coord": {
 52       "lat": <hidden>,
 53       "lon": <hidden>
 54     },
 55     "country": "US",
 56     "population": 805235,
 57     "timezone": -28800,
 58     "sunrise": 1611415194, // <-- Sunrise  Sunrise  Sunrise  Sunrise  Sunrise  Sunrise 
 59     "sunset": 1611451383 // <-- Sunset  Sunset  Sunset  Sunset  Sunset  Sunset
 60   }
 61 }

And here is json returned by >> wego -f json

{
	"Current": {
		"Time": "2021-01-24T01:00:00-08:00",
		"Code": 14,
		"Desc": "clear sky",
		"TempC": 8.63,
		"FeelsLikeC": 9.33,
		"ChanceOfRainPercent": null,
		"PrecipM": 0,
		"VisibleDistM": null,
		"WindspeedKmph": 1.7279999,
		"WindGustKmph": null,
		"WinddirDegree": 171,
		"Humidity": 80
	},
	"Forecast": [
		{
			"Date": "2021-01-24T01:00:00-08:00",
			"Slots": [
				{
					"Time": "2021-01-24T01:00:00-08:00",
					"Code": 14,
					"Desc": "clear sky",
					"TempC": 8.63,
					"FeelsLikeC": 9.33,
					"ChanceOfRainPercent": null,
					"PrecipM": 0,
					"VisibleDistM": null, <-- Visibility  Visibility  Visibility  Visibility  Visibility  Visibility 
					"WindspeedKmph": 1.7279999,
					"WindGustKmph": null,
					"WinddirDegree": 171,
					"Humidity": 80
				},
				{
					...
				}
				.
				.
				.
			],
			"Astronomy": {
				"Moonrise": "0001-01-01T00:00:00Z",
				"Moonset": "0001-01-01T00:00:00Z",
				"Sunrise": "0001-01-01T00:00:00Z",  <-- Sunrise  Sunrise  Sunrise  Sunrise  Sunrise  Sunrise 
				"Sunset": "0001-01-01T00:00:00Z" <-- Sunset  Sunset  Sunset  Sunset  Sunset  Sunset 
			}