Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Schedules #89

Draft
wants to merge 13 commits into
base: main
Choose a base branch
from
Draft

Schedules #89

wants to merge 13 commits into from

Conversation

leolost2605
Copy link
Member

@leolost2605 leolost2605 commented Jan 24, 2024 •
edited
Loading

Working prototype of schedules.
Currently available are:

  • Manual schedules
  • Daylight schedules (based on sunset, sunrise)

Settings:

  • Dark/Light mode
  • do not disturb
  • monochrome

My current way schedules are set up is as follows:

  • name (also acts as id)
  • Type (MANUAL or DAYLIGHT)
  • bool enabled
  • Dictionary private args - args specific to different types of schedules e.g. from and to with manual, latitude, longitude with daylight
  • Dictionary active_settings - settings that get set when the schedule becomes active
  • Dictionary inactive_settings - settings that get set when the schedule becomes inactive (these might just be the opposites of the active_settings)

Schedules are stored as gsettings with the type string a(ia{sv}a{sv}a{sv}) which is IMO actually a really cool, easy and fast way to store them.

Most of the schedule calculation logic is taken from the PrefersColorSchemeSettings

Starts to fix #64
Somewhat fixes #14 (toggling it will not disable the schedule)
Fixes #11

TODO:

  • name/id
  • enable/disable

@leolost2605
Copy link
Member Author

Some things to discuss here:

  • How should updating a schedule get handled?
    For example:
    Schedule is enabled and active but gets disabled. Should the inactive_settings get applied?
    And other way round etc.
  • The thing with nightlight is that we can't toggle it manually (or at least I don't know how) because GSD enforces scheduling. Of course we can work with that but since this would require quite a bit more code I'd like to leave this to a follow up PR
  • UI

@leolost2605
Copy link
Member Author

leolost2605 commented Jan 24, 2024 •
edited
Loading

For testing this is a valid key with two schedules

[('Night', 1, true, {}, {'dnd': <true>, 'monochrome': <true>}, {'dnd': <false>, 'monochrome': <false>}), ('Work', 0, true, {'from': <9.0>, 'to': <17.0>}, {'dnd': <true>}, {'dnd': <false>})]

@leolost2605
Copy link
Member Author

@danirabbit regarding UI any suggestions where to put it? (ike which plug, maybe desktop? Or maybe even a separate one?) To make it powerful we'd probably need a list where we can add schedules, enable/disable, edit and delete them and a dialog where the user can choose the type of the schedule, the settings that get toggled and possibly even the inactive settings that get toggled (maybe something like a reverse changes on becoming inactive - custom switch).
Alternatively we can also just provide some default schedules like night, work, etc. (which we should do anyways).

@danirabbit
Copy link
Member

@leolost2605 I think it might be its own new top level plugin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Focus Modes Dark mode snoozing Do Not Disturb scheduling
2 participants
@leolost2605 @danirabbit