-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Added configurable status indicator #2529
base: master
Are you sure you want to change the base?
Conversation
@eiachh Thank you Adam for taking a pass at this!! FYI ClusterInfo/Updated/Changed delta is indeed a bug ;( I am a bit divided on the approach, requirements and use cases... It seems there are 2 concerns at play: We want to customize the collapsed indicator styles (Currently canned!) We should extend k9s styles object to have a views.header section where users can match the collapsed header styles to match their theme. ie header.BgColor, header.FgColor and allow for overrides ie header.k9sVersion.FgColor, header.Cluster.FgColor, etc... We could extend the k9s config ui section with a header section ie header.collapse:true|false and header.format: string and users can customize their k9s header. Imho I think we could use an expression here parse it out ie something like: Another thought would be to consider the header-indicator as a view and customize the indicator in the custom views config vs doing a one off in the main configuration. Does this make sense? |
I get what you are saying and its a much better solution than how I did it. I will try to implement it soonish. The only confusing part is maybe this: header indicator is already a view isn't it? |
@eiachh Ah sorry Adam! I meant we could leverage custom views config aka views.yaml. But there really not that many options to configure the header indicator.... |
As in the ticket added a configurable status indicator ( from config.yaml ) 2447
There is one important note ClusterInfoUpdated and ClusterInfoChanged did use different values to insert into the same template cur.User, VS data.Context, if this was intentional, then I broke it. If it was an unnoticed bug then i fixed it and now both uses the same values.
If the user messes up the configuration and the format's %s placeholders don't match the amount of fields then the default config is used.