-
Notifications
You must be signed in to change notification settings - Fork 21
Conversation
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.
Thanks for making the PR, I'm definitely interested in adding this feature now. The PR looks good so far, just had some questions/comments. Keep up the good work!
@@ -13,7 +14,8 @@ export default class OptionsList extends Component { | |||
isLoading: true, | |||
mode: 'tab', | |||
showEmptySearchSuggestions: true, | |||
enableFuzzySearch: true | |||
enableFuzzySearch: true, | |||
theme: 'light' |
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.
Instead of using strings can we use something similar to enums? I think it would be sufficient to create an object that maps to the valid themes. Then we could just access them using Themes.Light
. This will help prevent mistakes with typos 😉. I realize the modes don't do this but that should probably be refactored later.
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.
ok, I'll have a look into it (:
@@ -30,7 +32,8 @@ export default class OptionsList extends Component { | |||
isLoading: false, | |||
mode: sakaSettings.mode, | |||
showEmptySearchSuggestions: sakaSettings.showEmptySearchSuggestions, | |||
enableFuzzySearch: sakaSettings.enableFuzzySearch | |||
enableFuzzySearch: sakaSettings.enableFuzzySearch, | |||
theme: sakaSettings.theme || 'light' |
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.
Same here with the theme enum thing
@@ -25,6 +27,15 @@ export default class GUIContainer extends Component { | |||
this.setState({ zoom }); | |||
}; | |||
|
|||
fetchTheme = async function fetchTheme() { | |||
const storedSettings = ( await browser.storage.sync.get(['sakaSettings']) ) || {}; | |||
console.log(storedSettings); |
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.
Once we are ready to merge this should be deleted
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.
again, was trying to figure stuff out at this point
- I haven't written a Firefox addon before
- I haven't dealt with (P)React before
when stuff wasn't working, I fell back on old-school debugging, only to find that the problem was that since I'd had to restart Firefox, it had unloaded my dev variant of the plugin and loaded back the original version 🤦♀️
console.log(storedSettings); | ||
const { sakaSettings } = storedSettings; | ||
// fall back on light theme when no settings | ||
const resolved = Object.assign({ theme: 'light' }, sakaSettings); |
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.
nice 👍
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.
Also enum thing here too
src/scss/themes/inverted.scss
Outdated
@@ -0,0 +1,3 @@ | |||
#GUIContainer[data-theme="inverted"] { | |||
filter: invert(100%); |
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.
Is this actually how this should work? I'm not too familiar with this type of accessibility work so not sure if there is more that needs to be done? Thoughts?
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.
This is a first-pass at a dark theme -- it works, but there are way better mechanisms for theming. Using data-theme='theme-name'
is a good approach (well, it's an approach used quite often), but a better theme would have scss inside this outer selector to apply predetermined colors and fonts (for a larger-font variant).
The theming part is going to take some design -- this was the simplest dark theme I could come up with to test the process and see if you'd even be interested in a PR -- I didn't want to spend ages on polishing a theme only to have the PR either sit or just be plain rejected.
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.
When the time comes to design proper themes, there should be at least (imo)
- a beautiful dark theme that most people wanting a dark theme would use (like how Dark Reader makes the web look)
- honestly, this is what I would use. The inverted theme makes the addon usable for me, but not particularly beautiful (: For me, a dark theme is more comfortable, but I can deal without. For some people, they can't see what's on the screen at all with a regular light theme, or they get light bleeding out of light areas over dark areas.
- a high contrast dark theme for accessibility (with larger fonts)
- a high contrast light theme for accessibility (with larger fonts)
- for some people, light-on-dark is difficult to deal with -- they just need larger fonts and inputs
both of the latter should be tested on machines where default font sizes have been set larger, to see if those settings apply to the addon's overlay. I have a friend who can test for me there. I can also get feedback from him on accessible color choices -- I remember having a discussion with him quite a while ago about the accessibility themes in Windows and what did and didn't work there.
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.
Sounds good, looking forward to seeing more!
Apologies for no movement on this PR -- last week was a bit hectic and I kinda forgot about it on the weekend ): I'll get to it though (: |
Codecov Report
@@ Coverage Diff @@
## master #103 +/- ##
==========================================
+ Coverage 58.50% 59.11% +0.60%
==========================================
Files 57 59 +2
Lines 711 724 +13
Branches 65 67 +2
==========================================
+ Hits 416 428 +12
- Misses 264 265 +1
Partials 31 31
Continue to review full report at Codecov.
|
♻️ enumerate themes for options list instead of hand-coding
@pureooze I've tidied up the requested places and the inverted theme, applied to the options page and started on theming the core of the addon. However, I now find lots of places with hard-coded colors in |
Yes that would be amazing 😃 |
hi; honestly, I don't have time to do all of this, so I'm quitting. I'm not going to try fooling myself that I'll "get around to this at some point". As a proof-of-concept, I think this PR had legs. If it had been accepted as a reasonable MVP, I think I might have had motivation to continue. Honestly, right now, I don't. I have too many other things I'd like to make. So I guess this is the end of the road. It was fun. |
Type of Change
Summary Of Changes
Why is this change needed?
Saka is really useful, but people with accessibility requirements may struggle to use it. Theming can help:
This PR is a proof-of-concept for theming in Saka. If the approach is acceptable, I'd like to make a "proper" dark theme, and perhaps a "large" theme, in separate pull requests. In addition, documentation probably needs to be updated -- again, I'll gladly do so if the approach to the feature itself is deemed acceptable.
Does this close any open issues?
Doesn't close, but does relate to #57
Checklist