-
Notifications
You must be signed in to change notification settings - Fork 6
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
Improve colour support #4
Merged
Merged
+633
−197
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
See #3 and Textualize/textual#3532 for some background. Some Plotext themes use ANSI colours and "hard code" things; others blend a lot better with Textual. In further testing it seems that out of the box "clear" and "pro" are a better fit within Textual *and* they work well with light/dark mode. So while not the most colourful of themes, they are the most pleasing to the eye as a default experience. Because of this, let's make Pro the default in both cases.
Rather than dumpster-dive the internals of Plotext.
Initially testing with a version of the default theme.
Instead, by default, use a theme that is far more textual-friendly and which is responsive to light and dark mode to start with. This means Textualize/textual#3532 is less of an issue right out of the gate as the default theme will blend in way better.
Also make textual-clear the same as Plotext's clear, in that it's all no-color. Because of this, switch the default theme for the widget to textual-default.
This should (and appears to) make things look more like you'd expect as a Plotext user, while making it look the same everywhere.
Rather than hand-patch each of the themes, I think it'll make more sense to just patch the odd one that really needs it, and then automate the patching of the rest.
Why do my eyes hurt?
This is what you get for copy/paste.
And, in doing so, make them the default auto-theme themes, and turn auto-theme back on by default. Overall this isn't really going to make much of a difference to how a plot looks out of the box; but it does mean we can tweak things a little as time goes on. It also means that if we change anything in the Textual design, this should follow. Right now, initially, it simply uses $accent for the ticks and leaves the background as the default.
mypy doesn't like it if you try and loop over a query, despite the fact that it works; I'm pretty sure pyright used to complain about this but it seems fine with it these days. No matter, let's keep everyone happy.
I think we may want to dial in the colour sequence (in other words the colours to use for subsequent plots of data) for some of the themes -- especially the textual-design-* themes -- so it will make life easier if there's a mode where you can clearly see what colours are used where. This should be it. It's like a test card mode.
Current state of the theme explorer. Screen.Recording.2023-10-24.at.15.24.09.mov |
This is still up for tweaking, but I feel this is narrowing it down to a pleasing palette of colours that work for dark and light mode, and for up to 20 plots in a single plot. I've kept almost all of the plotext-derived themes using their own sets, as I believe that's what people will be expecting, but for a couple (default and pro) I go with this curated set this seems like it'll likely be what people will use out of the box (actually I suspect most people will simply go with the textual-design-* themes). This might get a bit more tweaking; but I think this is close and sets the stage.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivated by Textualize/textual#3532 and #3, this PR aims to sets better default theme choices for the
PlotextPlot
widget, as well as adding a parallel set of themes that are the same as the Plotext-supplied, but which have all the colours transformed into RGB values, helping to ensure plots stay looking the same across various terminals and various terminal themes (on terminals that support themes).It also adds two (currently quite simplistic) "textual design" themes; one for dark mode and one for light mode. These are set as the default dark and light themes used by the
PlotextPlot
widget whenauto_theme
isTrue
.This all means that the weather example, which used to look like this with the "out of the box" colour:
now looks like this:
The main differences here being that the default theme now lets the background colour be the canvas and axes colour, and that the ticks colour (in other words the foreground of the axes) is a suitable version of
$accent
.Also added is a new example application which can be used to explore the themes provided by Plotext and this library.
Still deciding: if the
textual-design
themes should have hand-picked data colours (right now it's just using the default ones, made RGB).