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.

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

First run should prompt user to set timezone #172

Open
beroset opened this issue Aug 6, 2024 · 2 comments
Open

First run should prompt user to set timezone #172

beroset opened this issue Aug 6, 2024 · 2 comments

Comments

@beroset
Copy link
Member

beroset commented Aug 6, 2024

The problem

The first time the watch starts shows a short tutorial and then guides the user through setting the language, time and date. However, as @robthebold pointed out in a recent Matrix chat, the result is that the time is set in UTC rather than local time. Since having the timezone correct is important for travelers and anyone who synchronizes the calendar, the first run should prompt for the timezone after the language is set and before the time and date are set.

Possible fixes

Today, language, time and date settings are in https://github.com/AsteroidOS/asteroid-launcher/blob/master/src/qml/firstrun/FirstRunConfig.qml and largely duplicate those settings from asteroid-settings. We could:

  1. continue that model by duplicating and adapting the more complex timezone settings into asteroid-launcher
    Advantages:
    a. straightforward and consistent with other code in FirstRunConfig.qml
    b. does not require changes to any other code
    Disadvantages:
    a. large duplicated code which has to be separately maintained
    b. changes in structure mean that code can't be copied from asteroid-settings without modification
  2. copy the relevant settings pages and then run them using a state machine in FirstRunConfig.qml
    Advantages:
    a. copying the entire pages would make it easier to maintain over time
    b. may make the structure and state machine more visible to programmers
    c. keeps the settings separate from the driving logic
    Disadvantages:
    a. large duplicated code which has to be separately maintained
    b. more of asteroid-settings layer infrastructure would also probably have to be copied
  3. adapt asteroid-settings to be directly driven by asteroid-launcher
    Advantages:
    a. avoids duplicating code
    b. provides a general mechanism which might be useful elsewhere
    Disadvantages:
    a. more complex than the current cut-and-paste solution
    b. requires changes to two projects: both asteroid-launcher and asteroid-settings
@eLtMosen
Copy link
Member

eLtMosen commented Aug 6, 2024

Do i understand correct that, in layman terms, the goal of #3 is to call the existing settings pages for language, timezone, date and time from within the asteroid-launcher during the initial setup?

@beroset
Copy link
Member Author

beroset commented Aug 6, 2024

Do i understand correct that, in layman terms, the goal of #3 is to call the existing settings pages for language, timezone, date and time from within the asteroid-launcher during the initial setup?

Yes, that's it exactly. I hope to prototype this approach soon just to try it out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants