Conversation
| }); | ||
| break; | ||
| case 1: // when only start or end value is set; display an alert | ||
| window.alert(t('scheduleOneEntry')); |
There was a problem hiding this comment.
We don't use alert anymore as we have messageBox()
Alert may get auto-blocked and non-savvy users won't see any way to unblock it.
…lert; allow users to give up setting a new schedule or modifying existing one; reset the schedule UI on delete event
|
@irgendwie we need some users to try this branch and report bugs. Still, nobody really used this branch and hence we are not sure if it is buggy or not. I will fix the conflicts when it is ready to be merged |
|
@schomery Oh, so its ready to test? Will start using it then and report any issues! 👍 |
|
After setting a schedule time for a style and clicking outside of the input fields, I can log the following error in the console:
But maybe I'm just testing incorrectly, I cloned the repository and added the folder in chrome extensions via "Load unpacked extension...". Do I need to take additional steps? |
|
Looks like userstyles.org is no longer working with this old branch. I would really like to have this feature. What's the status? Sounded like it was pretty much working? Let's not let perfect be the enemy of the good! Might consider picking up squashing and rebasing this atop master.. EDIT: going to give it a try, since the change is purely additions. |
|
@mgsloan As you can tell, it didn't get enough testing and was eventually out of sight, out of mind.
Knock yourself out. If you get it working right, open a PR. We get the request every once in a great while, so you're not alone. Unfortunately, there was no one psyched about testing this feature when @schomery was willing to work on it. It's a shame the feature never made it, so I'd test it the next time around. I should've tested it the first time, but it's a feature I couldn't care less about personally, and I am lazy. |
|
@mgsloan If you're on it you might also use sunset times to prevent the need of constant adjustment. |
|
@narcolepticinsomniac Cool, makes sense! Perhaps such a feature might help with the insomnia ;) I want it because I mostly use my computer outside in the daytime, and light themes work best for that. But for nighttime, flux-like things + white themes just don't cut it. Plus it messes up all the colors. Here is some elisp that does it for emacs - https://github.com/GuidoSchmidt/circadian.el I squashed and rebased these commits as best as I could - https://github.com/mgsloan/stylus/tree/wip-rebased-scheduler . However, unfortunately it did not work, and there are no console errors. At the moment I don't feel like doing more involved work on it. Perhaps this branch will be useful to someone else in the future! Note to such a person: the I might return to this in the future. However, I tend to prefer code for configuration, so I am most likely to just hack it into some JS rather than implementing a UI @stonecrusher Yep, my emacs config uses location information for the schedule. Thanks for the library link! |
|
One thing that occurs to me is that the change here probably involves separate time configuration per theme. This'd be a major PITA when you want to change the schedule in bulk. Perhaps the solution might be to bake in the light vs dark distinction. So, the only per-theme thing would be an indication of whether the theme is used all the time, just daytime, or just nighttime. Then, there'd be configuration of geo coordinates or day start / end times. Sure, less flexible, but it would suggest the primary usage, and be a lot more convenient when you travel. |
|
I recently discovered that the disable all / enable all checkbox was sufficient for me, because I currently only use stylus for dark modes for nighttime use. I just implemented a quick night mode that does a global enable during the night, global disable during daytime: https://github.com/mgsloan/stylus/blob/night-mode/background/night-mode.js Since I only just wrote it, I haven't yet tested it with an actual sunrise or sunset, but I think it should work. If you want to use it, you can clone that branch and edit the latitude / longitude constants in the code. Might still get around to doing an implementation configurable in the UI. I have thought a bit about what the UI implementation should look like. I think it should be quite a bit different than this PR. Instead, something like:
|
7 participants
No description provided.