Help Themes #871
Replies: 4 comments 5 replies
-
|
I was thiking about asking people to publish packages to npm with keywords that can be used to identify an oclif theme.
This way cli users could create and backup their theme to npm and share it with other people. Then there would be a When running When running When running |
Beta Was this translation helpful? Give feedback.
-
|
I prefer option 3, but with a tweak to solve
What if |
Beta Was this translation helpful? Give feedback.
-
|
@mshanemc Possibly. Although someone might be expecting to be able to modify |
Beta Was this translation helpful? Give feedback.
-
|
This is what Im thinking as the output of each command in my suggestion using npm packages: Assuming that 3 packages with theme list
step 1: $ sf theme liststep 2: Fetching available themes ...step 3: if there are published themes Available themes
- theme_a description
- theme_b description
- theme_c description
exit 0step 3: when there are no published themes sorry but we could not find themes at https://npmregistry.com
exit 0theme installInstall theme asking Users to select from a list of available themes
step 1: $ sf theme installstep 2: Fetching available themes ...step 3: if there are published themes Please, pick one and press enter
- theme_a my precious theme a. allanoricil
> theme_b my precious theme b. mshanemc
- theme_c my precious theme c mdonnalleystep 3: when there are no published themes sorry but we could not find themes at https://npmregistry.com
exit 0step 4: theme was selected Installing `theme_b`...
`theme_b` downloaded
You can now set the theme using `sf theme set theme_b`
exit 0step 4: theme failed to be downloaded Installing `theme_b`...
`theme_b` failed to be downloaded
exit 1Install theme using its package name
step 1: $ sf theme install --name theme_cstep 2: Fetching theme_c ...step 3: if theme_c exists Installing `theme_c`...
`theme_c` downloaded
You can now set the theme using `sf theme set theme_c`
exit 0step 3: if theme_c does not exist sorry but we could not find `theme_c` at https://npmregistry.com
exit 0Install and immediately set theme using its package name
step 1: $ sf theme install --name theme_c --setstep 2: Fetching available theme_c ...step 3: if theme_c exists Installing `theme_c`...
`theme_c` downloaded
`theme_c` was set
exit 0step 3: if theme_c does not exist sorry but we could not find `theme_c` at https://npmregistry.com
exit 0theme setSet theme placing theme.json from the package into
step 1: $ sf theme set --name theme_cstep 2: if theme_c exists in the host machine at SOMEWHERE (path were themes are saved) `theme_c` was set
exit 0step 3: if theme_c does not exist locally `theme_c` was not found locally.
Please run `sf theme install --name theme_c` to install it
exit 0Theme Packageproject structure .
└── my-theme/
├── theme.json
└── package.json
{
...
"keywords": [
"oclif",
"theme"
]
...
}
{
"alias" : "red",
"bin" : "rgb(255, 255, 255)",
"command" : "#45C65A",
"commandSummary" : "#FFFFFF",
"dollarSign" : "#FFFF00",
"flag" : "#45C65A",
"flagDefaultValue" : "#1AB9FF",
"flagOptions" : "#45C65A",
"flagRequired" : "#FE5C4C",
"flagSeparator" : "#FFFFFF",
"flagType" : "#0EAEE8",
"sectionDescription" : "#FFFFFF",
"sectionHeader" : "#FFFF00",
"topic" : "#45C65A",
"version" : "#45C65A"
} |
Beta Was this translation helpful? Give feedback.
-
|
what if we make I vote for option 3 + Shane's suggestion:
then for
use-case:I plan to have 1 light and 1 dark theme, then switch it in a script that runs automatically when switching to light/dark mode. CLIs shipping themesCLIs can ship a
Sharing oclif themesI'm not sure how many people would use this feature, let alone start publishing and maintain an npm package. if requested, we could make See also:
Footnotes
|
Beta Was this translation helpful? Give feedback.
-
|
Love the idea of having a single file containing a But I'm stuck on wanting people to continue to edit the file after setting it. I'm imagining someone running Perhaps it should work something like this:
|
Beta Was this translation helpful? Give feedback.
-
💯 I like your proposal, setting the theme via |
Beta Was this translation helpful? Give feedback.
-
|
@AllanOricil had a good point that people might want to reuse themes across oclif CLIs (e.g. same theme for both With that in mind, here's another proposal based on Allan's comment:
And if there's demand for sharing themes we can add Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that would work for my use case, but I'm personally not concerned about having duplicates for +1 oclif CLIs. Thinking about usage of this feature: In my case I'll switch between a dark and light theme a few times per day (script runs when switching light/dark mode on mac), but other than that I don't expect myself to add new or update themes frequently so even If I would like to share a theme in +1 oclif CLIs I wouldn't mind having duplicates because:
about 3: this feels like a very specific case that we can safely support without exposing FS stuff via I feel confident saying that most people don't automate dark/light themes for terminal stuff, in those cases users will just use 1 theme that looks good on light/dark mode... so other than updating or trying a new theme every now and then, your local theme will not change that frequently to have to worry about your other's CLI theme being stale/duplicated. |
Beta Was this translation helpful? Give feedback.
-
#852 introduces themed help output (thanks to @AllanOricil). Users can create a theme for the help output in
~/.config/<CLI>/theme.jsonIn order to facilitate CLI users selecting a theme we are considering an new plugin,
@oclif/plugin-theme, which will contain a set of commands that allow users to list, set, and unset their theme.The big outstanding question here is how this would work best for CLI developers and their users.
Option 1
themesdirectory with their CLI.@oclif/plugin-themecan read this directory to get a list of themes that the user can select from.theme setwill take a--themeflag that corresponds to the file names found in thethemesdirectory@oclif/plugin-themewill copy the selected theme to~/.config/<CLI>/theme.json.Pro: This option requires no modifications to the existing implementation other than creating the new plugin.
Con: Users are locked into having their theme at
~/.config/<CLI>/theme.jsonOption 2
theme setwill take a--fileflag that points to any json file containing a valid themethemesdirectory with their CLI and advise users that there are recommended themes there if they would like to use them.Pros: Users can point the theme to any file on their machine
Cons:
~/.config/<CLI>/theme.jsonOption 3
theme setwill take a--fileflag that points to any json file containing a valid themethemesdirectory with their CLI. The themes in this directory would populate the help output fortheme setso that users are aware of the recommended themes.theme listwould also list out the recommended themesPros:
Cons:
~/.config/<CLI>/theme.jsonThemed
uxmethods?Another area we'd like feedback on is whether or not the themes would be helpful outside the context of help output. For instance, themes theoretically could be applied to the
uxmethods, especiallystyledObject,styledJSON,table, andtree. Is that something worth implementing?Beta Was this translation helpful? Give feedback.
All reactions