Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Terminal Watchface Improvements and added Weather. #2001

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

JustScott
Copy link
Contributor

@JustScott JustScott commented Feb 3, 2024

  • Use @vkareh's new weather forecast app as a template to implement the weather into the terminal watch face.
  • Use InfintimeTheme Colors instead of hardcoded hex values.
  • Reorder code to match the order of the UI.
  • Implement @vkareh's variable battery icon color to the battery percentage text.
  • Added a new InfinitimeTheme color, gray, and turn certain values gray when they contain no data, like weather.

terminal_weather_misty
terminal_weather_clear
terminal_less_gray
terminal_all_gray

I don't personally use the terminal watch face, so I'm looking for suggestions on what colors you guys want, and if I should change certain text like the steps# in the step counter.

Copy link

github-actions bot commented Feb 3, 2024

Build size and comparison to main:

Section Size Difference
text 375520B 992B
data 948B 0B
bss 63488B 0B

@vkareh
Copy link
Contributor

vkareh commented Feb 3, 2024

This is really cool, I like the graying out of n/a data!

How does it truncate if you have longer weather condition names, like Scattered Clouds or something?

Also, there seems to be a # sign after some of the lines, is that on purpose?

One suggestion though: the PS1 could be, say, lightGray so that it doesn't overpower the rest of the data, maybe then the time can be white so that it's easier to see at a quick glance?

I haven't really used this face a lot, but this PR might tip the scale for me.


using namespace Pinetime::Applications::Screens;

namespace {
lv_color_t temperatureColor(int16_t temperature) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes me think that we can make this part of the InfiniTimeTheme...

@JustScott
Copy link
Contributor Author

@vkareh I'm confused about the #'s at the end of the lines as well, they were already there so i didn't want to remove them incase there was a reason. As far as the trunacation, I modified your GetCondition function to GetSimpleCondition, which just uses a single word, like cloudy instead of Scattered Clouds... it misses out on some detail, but I just don't see a way of fitting more than one word.

// We lock satuation and brightness at 100% and traverse the cilinder
// between red and green, thus avoiding the darker RGB on medium battery
// charges and giving us a much nicer color range.
uint8_t hue = batteryPercentRemaining.Get() * 120 / 100;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any chance this can live elsewhere and we can reuse it here? Not super important, since my color PR may not ever be merged though 😛

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe in the theme too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I add it to InfiniTimeTheme.h in this PR, or should that be a seperate PR?

~WatchFaceTerminal() override;

void Refresh() override;

private:
Utility::DirtyValue<int> batteryPercentRemaining {};
Utility::DirtyValue<uint8_t> hue {};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this can be a local variable inside the function, no need to track its state at the class level

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

case Pinetime::Controllers::SimpleWeatherService::Icons::Clouds:
return "Cloudy";
case Pinetime::Controllers::SimpleWeatherService::Icons::BrokenClouds:
return "Cloudy";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what you did here. Clever.
It will conflict with the weather app PR, so we'll need to find a good middle ground if both make it into main

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I see this is a different, simplified, function. Makes sense now! 👍

@JustScott
Copy link
Contributor Author

This is with the time and date fonts white. I think the prompts look better in the first image with the lightGray, instead of the second image with gray. Thoughts?

terminal_lightgray_prompt
terminal_gray_prompt

@vkareh
Copy link
Contributor

vkareh commented Feb 3, 2024

I think the prompts look better in the first image with the lightGray, instead of the second image with gray. Thoughts?

In fully agree. Light gray looks better

@AlbeyAmakiir
Copy link

I really like the prompts being light gray. Good idea.

I'm a fan of each item being a different colour the way it currently is, and especially the [LABEL] part being the base terminal colour, as the colour helps direct my eye, but I do like the idea of the battery changing colour and the empty items being grayed out.

I dunno where the # has come from. It's not on mine, and I use the watchface all the time. Here's what mine looks like, at version 1.14.0:
IMG_20240204_133547

@FintasticMan
Copy link
Member

I agree with Albey above that I prefer the labels being white. The # symbols come from the way that the text was being coloured. It was done with #012345 text#, and I presume the final # wasn't removed at first. It has been fixed now though, I see.

I definitely prefer lightGray to gray, but perhaps if the labels are the same colour white works too?

Is there a reason that the same function for the weather description from the forecast app can't be used here? Are some words too long to fit?

I quite liked the colour variety of the current watch face. Maybe we can experiment with the colours a bit?

@JustScott
Copy link
Contributor Author

@FintasticMan Ah that's where the # came from, and yes more than a one word weather description overflows. Here's a version of the face with the labels white (#ffffff), the time and date using their original color value, and the prompts still using the lightGray value.

terminal_grayed
terminal_active

@JustScott
Copy link
Contributor Author

JustScott commented Feb 4, 2024

What are your guys thoughts on replacing the 'you have mail' text for new notifications, with just turning the the prompts orange (or some other color)?

terminal_orange_prompts

@AlbeyAmakiir
Copy link

The extra line is nice and obvious. Only changing colour wouldn't communicate to new users of the face why it has done so. Moreso, communicating any information through colour alone makes it inaccessible to colourblind users.

That said, I'm not opposed to adding that colour to the mail text. That could make it stand out even better than it does now, I think.

Was there another reason you suggested changing the colour instead of having the line?

@JustScott
Copy link
Contributor Author

@AlbeyAmakiir I just thought it was a bit out of place for a terminal watch face to have random text above the first prompt appear. But you're right, just changing the color wouldn't work, I hadn't taken into account color blind users.

I think having a more realistic terminal message could fit the lore a little better, I made an example of a background 'notify' job completing in the picture below, but if anyone has a better one let me know. (I'm also completely fine with leaving it as it was if that's how people prefer it).

terminal_notification

@AlbeyAmakiir
Copy link

Hmm, I'm not sure. Having it at the top does have the advantage that it's right next to the direction in which you need to swipe for notifications, which I only noticed because your alternative is at the other extreme. But you're right it's a little off-lore. I also considered a [MAIL] entry in the output, but that doesn't have the benefit of being entirely invisible until there's a notification, which seems like it might be important for grabbing attention.

So it might be best to leave it as is, but I'm chill if others feel differently. I'm not sure how to weigh up the pros and cons of all these options.

char tempUnit = 'C';
lv_obj_set_style_local_text_color(weather, LV_LABEL_PART_MAIN, LV_STATE_DEFAULT, temperatureColor(temp));
if (settingsController.GetWeatherFormat() == Controllers::Settings::WeatherFormat::Imperial) {
condition = Symbols::GetSimpleCondition(optCurrentWeather->iconId);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is in the wrong scope. It also doesn't need DirtyValue tracking.

I suggest just calling it in the lv_label_set_text_fmt:

lv_label_set_text_fmt(weather, "#ffffff [WTHR]# %i°%c %s ", temp / 100, tempUnit, Symbols::GetSimpleCondition(optCurrentWeather->iconId));

Then get rid of the condition variable.

case Pinetime::Controllers::SimpleWeatherService::Icons::Snow:
return "Snowy";
case Pinetime::Controllers::SimpleWeatherService::Icons::Smog:
return "Misty";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is misaligned

Comment on lines 40 to 57
case Pinetime::Controllers::SimpleWeatherService::Icons::Sun:
return "Clear";
case Pinetime::Controllers::SimpleWeatherService::Icons::CloudsSun:
return "Cloudy";
case Pinetime::Controllers::SimpleWeatherService::Icons::Clouds:
return "Cloudy";
case Pinetime::Controllers::SimpleWeatherService::Icons::BrokenClouds:
return "Cloudy";
case Pinetime::Controllers::SimpleWeatherService::Icons::CloudShowerHeavy:
return "Rainy";
case Pinetime::Controllers::SimpleWeatherService::Icons::CloudSunRain:
return "Rainy";
case Pinetime::Controllers::SimpleWeatherService::Icons::Thunderstorm:
return "Stormy";
case Pinetime::Controllers::SimpleWeatherService::Icons::Snow:
return "Snowy";
case Pinetime::Controllers::SimpleWeatherService::Icons::Smog:
return "Misty";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these should follow the OWM main group names more closely:

  • Clear
  • Clouds
  • Clouds
  • Clouds
  • Drizzle
  • Rain
  • Thunder(storm) <--- Thunderstorm doesn't fit, but Thunder does
  • Snow
  • Mist <--- This one doesn't have a single name for the main group, but I've seen several apps defaulting to Mist, since it's the first one in the atmosphere condition group.

terminal-weather

uint8_t hue = batteryPercentRemaining.Get() * 120 / 100;
lv_obj_set_style_local_text_color(batteryValue, LV_LABEL_PART_MAIN, LV_STATE_DEFAULT, lv_color_hsv_to_rgb(hue, 100, 100));
lv_label_set_text_fmt(batteryValue, "#ffffff [BATT]# %d%%", batteryPercentRemaining.Get());
if (batteryController.IsPowerPresent()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should call IsCharging() instead, as once it reaches 100% the controller will stop charging once the battery is full. Also, displaying 100% Charging looks odd.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree.

@vkareh
Copy link
Contributor

vkareh commented Feb 5, 2024

@JustScott

What are your guys thoughts on replacing the 'you have mail' text for new notifications, with just turning the the prompts orange (or some other color)?

I agree with @AlbeyAmakiir with regards to accessibility. Color-coding on a notification is not great UX. The [1]+ Done line at the bottom looks really cool, but the implication is that a background job is finished. The Done message is bash's rendering of a POSIX signal (I think SIGHUP) and so the text can be anything (bash has built-ins for Done, Stopped, Exit, etc...). I think the message can very well be [1]+ Notify, a reasonable rendering of a made-up SIGNOTIFY POSIX signal (we're all playing make believe here anyway, right?)

Playing with a terminal, I recreated what the flow would look like this (and yes, I modified my PS1 and created a now alias just for this test 😝):

user@watch:~ $ now
[TIME] 12:28:51
[DATE] 02/05/24
user@watch:~ $ echo "You have mail." &
[1] 71270
You have mail.
[1]+  Done                    echo "You have mail."
user@watch:~ $ now
[TIME] 12:28:54
[DATE] 02/05/24
user@watch:~ $ notify-send "You have mail." &
[1] 71281
user@watch:~ $ now
[TIME] 12:28:59
[DATE] 02/05/24
[1]+  Done                    notify-send "You have mail."
user@watch:~ $ 

Based on this, the signal message can be either before the top prompt (in the case of using echo &) or before the bottom prompt (in the case of using notify-send &).
In both cases it shows up before the prompt, and never after it.

Translating this to the watch face, I think we have two options that could work and satisfy the lore:
InfiniSim_2024-02-05_123151 InfiniSim_2024-02-05_123308

I personally prefer the first one.

@vkareh
Copy link
Contributor

vkareh commented Feb 5, 2024

Not sure if this is desired, but continuing on the theme/lore aspect, I recolored the watchface to use a 3-bit color space (8 colors). Maybe better to just use LVGL's pre-defined colors (which more or less simulate a 4-bit color space)
InfiniSim_2024-02-05_142017

Not sure, maybe it's too much...

@AlbeyAmakiir
Copy link

I won't know for sure until I see it on the actual watch screen, but on my computer the 3-bit colours look a bit too harsh. Maybe it'll be fine irl, though? I'm not sure.

I definitely prefer the notify text being at the top over the bottom. (Also, I really appreciate that you actually tested that on a terminal. Fantastic. XD )

@vkareh
Copy link
Contributor

vkareh commented Feb 12, 2024

@AlbeyAmakiir I agree - the 3-bit colours are not great, to be honest.

@FintasticMan
Copy link
Member

I would say it would be best to break the weather display out of this PR into its own, so that we can discuss that separately from changing the UI.

@pbone64
Copy link

pbone64 commented Mar 8, 2024

I much prefer the white prompts. It fits the terminal theme better (at least in my experience) and using less colours makes the face as a whole less busy.

@Int-Circuit
Copy link

+1 having weather on terminal watchface would be great, as it is more precise for the number of steps than pinetimestyle

Use @vkareh's new weather forecast app as a template to implement
the weather into the terminal watch face. Use InfintimeTheme Colors
instead of hardcoded hex values. Reorder code to match the order of
the UI. Implement @vkareh's variable battery icon color to the battery
percentage text. Added a new IninftimeTheme color, gray, and turn
certain values gray when they contain no data, like weather.
Labels are now a static white #ffffff, while the values
can still dynamically change color.
defining it first. changed the 'you have mail' to '[1]+ Notify, to better
align with terminal lore. Use `IsCharging` instead of `IsPowerPresent` to
stop displaying the 'Charging' text once the battery's full. Update the return
values for weather condition in `GetSimpleCondition` to match the standard
names used in the rest of the project.
@JustScott
Copy link
Contributor Author

JustScott commented Oct 3, 2024

I would say it would be best to break the weather display out of this PR into its own, so that we can discuss that separately from changing the UI.

I created a new PR without the weather changes: #2135, I also created a PR for the simpler weather condition change: #2134

Now I'm wondering if it would be better to create a new PR for just the weather changes on the current main branch, and close this PR, or to reset the code in this PRs branch to the main branch, and then add the changes. In my opinion it would be more clean to just create a new PR and close this one.. but I'm often wrong lol.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants