feat(calendar): add calendar widget

[sophacles]

A calendar widget that with some display options and styling for individual dates.

This widget displays the month provided to it in the constructor. (see docs and the example for more info).

One thing to note: This pulls in a new dependency, the time crate. Since this adds a dependency, it might be worth putting the widget behind a feature flag - I'm happy to do so if that's desired.

[joshka]

Looks great! Some minor comments only

[joshka]

Changes for header LGTM.

I'm not sure whether the time dependency will be an actual problem for anyone (I'd guess it's probably a fundamental enough crate that probably not). The bigger issue on that idea though is that if you do plan to move to using chrono down the line, perhaps feature flagging on whether to use time or chrono calendars could be worth doing up front. I don't have any strong leanings either way on this. It could be best to just leave this until it's an issue.

I'd lean towards adding the change to calendars::Month in this PR the name just seems more correct and changing the widget names down the line would break more dependents.

Slapping an approve as no big deal if you don't make that change either.

[sophacles]

I fixed up the docs to remove the mention of Chrono. That was leftover from when I was building this for a personal project, and I chose to not migrate to chrono there. We can decide how to add support for it if there's a desire for it from users.

About naming, i did the namespaced thing, but went with calendar::Monthly instead of calendar::Month because time::Month is also a type, and those two presumably will be used to gether often (for example, the example).

[sayanarijit]

Should we put calendar and other similar new-dependency-introducing widgets behind feature flags? @orhun @mindoodoo

[mindoodoo]

Hmm, what would you name the feature ?

[sayanarijit]

Hmm, what would you name the feature ?

widget-calendar?

[sophacles]

I put in the machinery for the feature and named it widget-calendar. It's easy to change if something else is decided.

ed: The construct feature_name = ["dep: time"] is newer than MSRV. How would i do this in a way that makes 1.59 happy?

[orhun]

I didn't understand why you went with dep:time instead of time, why is that required?

[sophacles]

why is that required?

Apparently it isn't :). I'm still learning about some of these Cargo directives and I think I misunderstood some of what I read.

Pushed a fixup

[orhun]

Just tested and it works well. GJ! 🎉

One question though, is it possible to add tests for this?

[sophacles]

I can add tests (i think). I'll see what I can get in place over the weekend.

[sophacles]

I've added some tests for the widget, as well as for the date styler.

One thing to note, I'm not sure if CI will actually run the tests, because I don't know if it builds with default features or does something "smart". I added a feature all-widgets in my latest commit, which currently just specs widget-calendar, but as we add other widgets behind feature flags, I presume it will get more entries. It also allows for a simpler testing with cargo test --features all-widgets

edit - the output of the test runners in CI shows that the calendar tests were not run. I'm not sure how to change what features are enabled for the runner.

[orhun]

I think you can update Makefile.toml like this for running tests for all-widgets feature:

diff --git a/Makefile.toml b/Makefile.toml
index 8afba0a..db9354f 100644
--- a/Makefile.toml
+++ b/Makefile.toml
@@ -100,11 +100,11 @@ args = [
 ]
 
 [tasks.test-crossterm]
-env = { TUI_FEATURES = "serde,crossterm" }
+env = { TUI_FEATURES = "serde,crossterm,all-widgets" }
 run_task = "test"
 
 [tasks.test-termion]
-env = { TUI_FEATURES = "serde,termion" }
+env = { TUI_FEATURES = "serde,termion,all-widgets" }
 run_task = "test"
 
 [tasks.test]

[sophacles]

Thanks @orhun - that looks like it did the trick, I can see the calendar tests being run now.

[mindoodoo]

This looks awesome man !