So when I recently discovered The Right Way to Check the Weather with a short and simple command line (like curl wttr.in) I thought I was finally there. The documentation said there were many options -- including some that seemed ideal for the tiny zipit screen. But no, sadly, I was not quite there yet. The zipit is simply not made of modern stuff, and so was not quite up to the task. Actually that's not completely true. An ASCII only -- black and white -- weather report is supported. But who the heck wants that? The weather is life itself, and black and white just doesn't cut it.
So I set it aside and went about other business, until someone else on the zipit IRC channel made note of wttr.in and got me thinking. Apparently some ideas had germinated with the passing of time, because I now realized I could make a filter to re-tune the output for the zipit. Yeah, that might just do it.
The two most obvious problems I'd noticed with the standard colorful weather output were the use of fancy xterm 256 color escape codes, and some utf-8 unicode glyphs that I just didn't have. The old fbcon terminal only supports the escape codes for an ancient, under-powered 16 color palette. And the tiny psf console font simply has no room to waste on a dozen subtle variations of the standard single quotation mark. How many different ways can you tilt that thing? And honestly, how often am I gonna use that lightning bolt glyph? So I ran about a zillion weather reports from various airports (and some extra tall mountains) and built up an enormous sed filter to coral the nonsense into a smaller pallette and a reasonable character set. As you can see, the 16 color spectrum is quite limited, but gets the job done adequately for the temperature and wind speed ranges.
Yeah, that "dark yellow" is really more brown than orange, but whatcha gonna do?
Here's the filter script:
zipweather
After a while I realized the 5x8 zipit font provided just enough text to fit something slightly more advanced -- an actual forecast.
At that font size I can't actually read it, but I can still make out the pictures.
The zipforecast script should be available here shortly...
Update June 12, 2020
And...suddenly I'm reminded on the zipit IRC that the st-sdl terminal can handle xterm color escape sequences, so I had to try it. I did a quick hack to set the display to the 320x240 zipit screen size and built it on the laptop to see if it was viable. The larger color table looks pretty good. I noticed that it also handles the UTF-8 characters, including the lightning bolt, which is a nice bonus.
Note the many subtle shades of orange and greenish yellow.
It was easy enough to build on the zipit. But once again pthreads gave me segfaults when I tried to run it on a zipit with IZ2S. Eventually I remembered to search the blog for hints on that. This time I ended up linking with -pthreads before and after the SDL libs, and I also had to remove an extraneous -lc early in the link args to make it work.
Once again, the weather here is mostly greenish yellow.
The truetype dejavu font struggles a bit at this size. And it's taller than the 5x8 psf font, so some of the forecast scrolls off the top. Also, I still need to add support for the weird zipit keyboard. Gotta borrow that mess from links, or maybe pspmaps.
Update June 20, 2020
And...it turns out the clunky truetype font looks much, much better with antialiasing enabled, although It's still too tall. And there are some questionable spacing choices on the 80 and the 86. Is it a failed attempt at kerning? Maybe I should add a command line option to select another font.
The trend is now slipping into the orange end of the spectrum.
Meanwhile the zipit keyboard works pretty well with a simple change to ignore the Alt key modifier whenever there's a nonzero unicode value available for a key press event. All one line fixes so far. I also borrowed a slightly larger chunk of code from the current X11 version of st to support for the DSR Device Status Report escape sequence required to make qe work properly. It probably wouldn't be much trouble to import the truecolor escape sequence support from there as well. But first I'd need to find an interesting shell app to test that with.
At this point I've got my st-sdl patches up on github and need to start thinking about making a release.
But first a quick distraction from the comments... I took the mydingux SDL myterm program mentioned by user Unknown in the comments below for a spin. And while it clearly does not support enough escape sequences to do a proper job rendering the weather, it does provide support for a nice shiny background image that I'm gonna probably borrow for st-sdl.
I do like the shiny stuff.
Ok, I realized that a colored background image is only easy if you don't support the escape codes for background colors on the text (myterm does not). So I decided to release an iz2s st-sdl binary before I dive into that mess.
https://github.com/deeice/st-sdl/releases/tag/v0.3
Looking forward to trying out st-sdl. I've been looking for a decent SDL based terminal program. The best option I've been able to find so far is this: https://sourceforge.net/p/mydingux/code/ci/master/tree/myterm/ Not sure how it compares to st-sdl, but might be worth checking out.
ReplyDeleteThat myterm code looks fairly minimal compared to st-sdl, and even when compared to fbcon. So for the zipit I would probably only use it as example code, or maybe if I wanted to fold a simple terminal into gmenu2x. That mydingux code tree has some other interesting goodies though. I wonder how the rockbox port differs from mine.
ReplyDeleteI've been reading about sixel ( https://github.com/libsixel/libsixel ). Wondering if that would help with displaying graphics on systems that aren't running X Windows. The key would be making sure there was sixel support in the terminal program. I've been wondering how hard it would be to add sixel support to st-sdl or myterm.
ReplyDeleteI've tinkered with sixel graphics scripted in DCL on a decterm, but not much more than that because I really dislike VMS. Plus I'm not too keen on the number 6 these days. But it does seem like it could be a nice fit for the zipit.
ReplyDeleteI'd look at the mlterm sources to see how hard it'd be to borrow the sixel support code, but the endless insanity over the fake plandemic is really getting me down these days. I find it difficult to get motivated to do anything, other than try and keep up with the coded messages in the fake news to see if it's *ever* gonna end.
However, the increasing repetitions of the Number 14 seem promising, but I'm Nowhere Near fluent in the Numbers, so I can't pin a time frame on when that'll peak. Until then the sixel stuff goes into the backlog of promising ideas.
Thanks for the idea though. It's a good one.