ThemeScheduler
ThemeScheduler copied to clipboard
facelessuser
Prevent ST from blinking from one to another scheme
Yes, you are right, when I disable linter, ThemeScheduler works great. So my fix seems, is a workaround for ST with lint enabled.
On Sun, Feb 25, 2018 at 12:15 AM Isaac Muse [email protected] wrote:
Lint issues can be ignored. I need to update the lint environment.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/facelessuser/ThemeScheduler/pull/14#issuecomment-368252178, or mute the thread https://github.com/notifications/unsubscribe-auth/ADWS_PkvH6V6sjTIiWBz3vt4g2YW14iOks5tYF_JgaJpZM4SSAV1 .
-- With best regards,
Art Gabdullin
Telegram, WhatsApp: +7 912 494 ‒ 77 ‒ 45 Skype: Gabdullin.AT http://is.gd/GabdullinAT LinkedIn: ArtGabdullin https://www.linkedin.com/in/ArtGabdullin
I think you are mistaking what I was saying. When I was referring to linting, I was referring to linting in this pull requests continuous integration tests below.
As for conflicting with a linter plugin, I'd have to better understand what that linter plugin is doing. If it is modifying the color scheme when ThemeScheduler swaps themes, then that may be something to take up with the linter. But if there is a specific, fundamental issue with ThemeScheduler, then we may need to fix it. Anyways, more details would be needed for me to accept this as I am not sure exactly what this is attempting to fix.
I still don't feel I understand what the problem is and how this fixes said problem. I need some more information to determine if this is a reasonable pull, or if something else needs to be done. I'm afraid if I can't get anymore information about this, I'll have to close this request.
Well, I think I can explain how you can reproduce the problem.
So we need a clean sublime build 3143 without any plugins installed Then Install Package Control, and ThemeSchedular via Package control
So content of Data\Packages\User\Preferences.sublime-settings is: { "color_scheme": "Packages/Color Scheme - Default/Breakers.tmTheme", "ignored_packages": [ "Vintage" ], "theme": "Adaptive.sublime-theme" }
And the content of the Data\Packages\User\ThemeScheduler.sublime-settings is: { "enabled": true, "themes": [ { "theme": "Packages/Color Scheme - Default/Breakers.tmTheme", "time": "08:00", }, { "theme": "Packages/Color Scheme - Default/Monokai.tmTheme", "time": "19:00", } ] }
And current time is 22:00
So in my case, Windows 10, when I run ST it will load *Breakers *them first and then after 3 seconds it will load Monokai Yes, it is ok, bc plugin needs time to be loaded and perform theme changes. And if I close and open ST again it again firstly uses theme form main settings file *Breakers *and after 3 seconds load Monokai
On Sun, Mar 4, 2018 at 7:30 PM Isaac Muse [email protected] wrote:
I still don't feel I understand what the problem is and how this fixes said problem. I need some more information to determine if this is a reasonable pull, or if something else needs to be done. I'm afraid if I can't get anymore information about this, I'll have to close this request.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/facelessuser/ThemeScheduler/pull/14#issuecomment-370233479, or mute the thread https://github.com/notifications/unsubscribe-auth/ADWS_Aq0KpzKnBSOQY1AUoFXdOCgeXxKks5ta_qLgaJpZM4SSAV1 .
-- With best regards,
Art Gabdullin
Telegram, WhatsApp: +7 912 494 ‒ 77 ‒ 45 Skype: Gabdullin.AT http://is.gd/GabdullinAT LinkedIn: ArtGabdullin https://www.linkedin.com/in/ArtGabdullin
Okay, so you are just complaining about refresh of the theme on startup because the theme isn't saved to preference file. So on close, you are left with whatever was originally set, and not what is currently set.
I'll have to do some testing. I'm not sure if you noticed, but there are two paths, a safe save (which manually reads and saves the user preference file), and then there is the path you are editing that uses the API. We initially use the safe save which should physically write the preference file, but additional theme/scheme updates will use the API, but not use the API to save (which you have added).
Safe save came about to avoid a weird case where we were using the API too early and forced the user settings to be erased when we saved. To avoid that, we read the physical settings file sidestepping the API
I need to make sure using a save here never causes the issue to return. So let me investigate.
ok, thank you!
On Mon, Mar 5, 2018 at 1:15 AM Isaac Muse [email protected] wrote:
Okay, so you are just complaining about refresh of the theme on startup because the theme isn't saved to preference file. So on close, you are left with whatever was originally set, and not what is currently set.
I'll have to do some testing. I'm not sure if you noticed, but there are two paths, a safe save (which manually reads and saves the user preference file), and then there is the path you are editing that uses the API. We initially use the safe save which should physically write the preference file, but additional theme/scheme updates will use the API, but not use the API to save (which you have added).
Safe save came about to avoid a weird case where we were using the API too early and forced the user settings to be erased when we saved. To avoid that, we read the physical settings file sidestepping the API
I need to make sure using a save here never causes the issue to return. So let me investigate.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/facelessuser/ThemeScheduler/pull/14#issuecomment-370260088, or mute the thread https://github.com/notifications/unsubscribe-auth/ADWS_E0FNAKKQNYVZXp-RH9LIVVWCCDlks5tbEtzgaJpZM4SSAV1 .
-- With best regards,
Art Gabdullin
Telegram, WhatsApp: +7 912 494 ‒ 77 ‒ 45 Skype: Gabdullin.AT http://is.gd/GabdullinAT LinkedIn: ArtGabdullin https://www.linkedin.com/in/ArtGabdullin