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

WIP: Add color selection in gmtlogo based on day of year #1986

Closed
wants to merge 2 commits into from

Conversation

PaulWessel
Copy link
Member

@PaulWessel PaulWessel commented Nov 5, 2019

Curently only added Halloween and Christmas as special color periods, with default being the usual GMT logo colors. I switch to the special color if the day is within ±4 days of the actual holiday. We can add more colors for holidays as we figure them out. Adding more colors is simply adding another line of strings in the structure, increment the structure size, and add an if-test for the day range. Addresses #1958.

Curently only added Halloween and Christmas as special color periods, with default being the usual GMT logo colors.  I switch to the special color if the day is within ±4 days of the actual holiday.  We can add more colors for holidays as we figure them out.
@PaulWessel PaulWessel requested a review from a team November 5, 2019 07:25
@seisman seisman added this to the 6.1.0 milestone Nov 5, 2019
@seisman
Copy link
Member

seisman commented Nov 5, 2019

It won't work for Chinese New Year, since the date of Chinese New Year isn't fixed in the Gregorian calendar. For example, the Chinese New Year is on Feb. 5 for 2019, and Jan. 25 for 2020. Other festivals/events may have the similar issue (e.g. world cups).

BTW, maybe add a -T<theme> option to specify the logo theme, so that we can have a Christmas logo even it's not Christmas.

Since the logo theme are defined by combination of six colors, we can even add modifiers to -T, allowing users to design any combinations of colors in the command line.

@joa-quim
Copy link
Member

joa-quim commented Nov 5, 2019

Easter also changes in a non trivial way but those dates are pre-computeable in advance. We could have a list of dates for the next 10 years (or, more optimistically, a 1000th years)

@PaulWessel
Copy link
Member Author

Presumably there is an algorithm to figure out such things - same with Easter for instance. I don't like the idea of a -T that lets users select or control the colors. At best, I would be OK with an option to override any auto-coloring we think up and give the plain GMT standard logo colors. I am reasonably happy with the Halloween colors but unhappy with draft 1 of Christmas. I think for Oct 21 (GMT anniversary) we can add some extra plot calls to add a gold star and a "xxth anniversary!" text somewhere, but not sure about the rest. Need more discussion here.

@PaulWessel
Copy link
Member Author

And yes, when the world cup takes place is not computable, so probably not a good idea anyway. Brazilian carnival, perhaps @leouieda ?

@leouieda
Copy link
Member

Brazilian carnival, perhaps @leouieda?

Carnaval is also lunar and tied to Easter, actually. But what would be the color for Easter?

@PaulWessel
Copy link
Member Author

Not sure, purple and something? Anyhow, not sure anyone (me included) is motivated to implement an easter calendar tracker (I am sure one exists in C somewhere) to actually do these things. So this is definitively a back burner issue.

@remkos
Copy link
Contributor

remkos commented Jan 8, 2020

Sounds like WIP. Changing title.

@remkos remkos changed the title Add color selection in gmtlogo based on day of year WIP: Add color selection in gmtlogo based on day of year Jan 8, 2020
@PaulWessel
Copy link
Member Author

Thanks, this has stalled for lack of (a) good color candidates for easter, Christmas, kwanza, Chinese new year, etc and (b) algorithms needed.

@seisman seisman modified the milestones: 6.1.0, 6.2.0 Mar 25, 2020
@PaulWessel
Copy link
Member Author

While a fun idea, it seems there is considerable work needed to get this to work, just for the privilege of doing a random logo on some days. Not super helpful for users, and probably not the best use of our time. Shall we agree to let this one die?

@KristofKoch
Copy link
Contributor

I can live without it.

@PaulWessel
Copy link
Member Author

Killing this as not important.

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.

None yet

6 participants