-
-
Notifications
You must be signed in to change notification settings - Fork 101
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
Add a custom theme dialog #662
Conversation
@danrabbit I would appreciate your comments on this. I added the extra labels as it didn't seem obvious to a new user why there were two very similar color buttons with only one label. The main flaw with this is that it is not possible to save a custom theme permanently - if you switch back to a builtin theme it overwrites your custom theme and you cannot return to it without rebuilding it. It might be better to fix that in a new PR as there is more than one possible solution - e.g. a new setting or a file in the user home. |
I see from the prior art in #418 that no-one else thinks the extra labels are necessary so I'll remove if required. |
There are also some possible extra refinements like using palette colors for foreground/background but that can be done in another PR. |
I think we should solve the issue of persisting the custom palette before exposing this toggle so that we don't have an immediately broken feature. We should probably make sure that the |
Yeh, that makes sense. |
# Conflicts fixed: # src/Widgets/TerminalWidget.vala
@danrabbit After merging master and making relevant changes, the custom theme now persists. I have moved the "Color Palette" header to before the background/foreground buttons because although the palette strictly speaking does not include these, to the average user they are just some more color settings. I have also changed the reset button to reset the foreground/background/cursor colors for the same reason. Can importing/saving custom themes be left for a later PR, if required? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two small questions, but other than that totally happy with this as an initial implementation. Let's get this in and then smooth out the flow a little bit/do other features in future branches
Co-authored-by: Danielle Foré <daniel@elementary.io>
I have implemented your suggestion re fallback palette as it simplifies the code and the issue of possible invalid colors in the settings (presumably due to manual editing) is unlikely. We now fallback to a default palette if any of the custom colors are invalid rather than replacing only the invalid color. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One suggestion and a comment
Ok, so you want to keep correcting individual colors; I'll revert to that. I just thought that this pretty unlikely to be required in practice so simplified it. I guess if we implementing importing customs themes it raises the risk of invalid colors being imported. |
Co-authored-by: Danielle Foré <daniel@elementary.io>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it's just a little bit less destructive. This looks good!
Pulled from #552
Fixes #418
Potentially address #39
Potentially addresses #71
Potentially address #501
Partially addresses #507
Potentially address #632
Additional work: