The way this works is:

1. io.elementary.switchboard.locale/first-day changes, and sets a (translatable) string of the day that it is ("Sunday" is default)
2. This will propagate to whatever place reads this such as a calendar widget or some such, and reorders the columns to reflect the setting.
3. ???
4. Profit!

Now all you need, is to use this on apps or indicators that have a calendar grid, to reorder the grid based on this setting.

Actually, going to need some help with save-stating this on the checkbox, as currently it jumps to Sunday.

Ready to review.

Could you guide me on how to make a ranged gschema? I've never done that type of thing before.

As for the rest about checking on code if it's on the range, I'd wager it should be fixed if the gschema is ranged, wouldn't it?

I am not quite sure what happens if code tries to write an out of range value to a setting so it is better to be sure this cannot happen one way or another.

There we go.

After addressing things, there's a small lag on first open, but shouldn't be anything bad.

Review points addressed. 👍

If we can read the first day of the week from Posix then we do not really need a combobox ...

There a Posix enum NLTime.FIRST_WEEKDAY in posix.vapi - maybe this is useful?

The thing is that it's not the problem this PR is solving really reading from Posix and automatically setting things; it's solving the "I'm Spanish, but my system is purposefully in English because I'm studying it or my company set it so, or whatever the reason, so calendars starts on Sunday instead of my country's week start. I can customize via the combobox to make it familiar to me, and keep using my system in English.".

Also, we already do that, but now we can show to the user the setting via this, in a future PR as well.

Please understand that further efforts on Locale and Account Services or ideas like that would bloat this PR and make it not follow the (unwritten?) guideline of a PR doing one thing per PR as I was told many times to do.

I know this is out of scope, but since there's a discussion already here I don't know where better to put it. I put a bit of info about the posix locale in the original issue. There's also some stuff about this over in the calendar code.

Also, there's a potential issue with the WEEK_1STDAY variable here. According to posix, the numbering of each day of the week depends on the value of that variable. So either we could take that into account here, or assert that every day of the week has the same number no matter what posix says. I put a comment to this effect in the Calendar PR.

I am happy for this to be merged on the assumption that further work will be done to ensure that the default setting for this is correct.

I'm happy to do that since I did the week start stuff in calendar, but it will be a while before I can guarantee. But in theory a "correct" solution that accounts for the posix stuff should be pretty similar to what's in that codebase, assuming I did it right.

Good - just needs to @danrabbit to sign off on it now.

I feel like this should start at 1, not 0 because as @mcclurgm points out in that calendar code block GLib uses 1-7 and we could reserve 0 for a future "automatic/from locale" setting

I feel like this should start at 1, not 0 because as @mcclurgm points out in that calendar code block GLib uses 1-7 and we could reserve 0 for a future "automatic/from locale" setting

But AFAIK, the Evolution key starts at 1 for Monday. So which futureproofing are we going to push towards? Besides, I think work towards an Automatic Locale thing for the combobox can be done in a new PR.

But AFAIK, the Evolution key starts at 1 for Monday. So which futureproofing are we going to push towards?

Not sure what other future proofing you're referring to? It seems to me like matching Evolution would be a good thing.

I'd personally support changing to 1 = Monday, since then we could use it directly as a GLib.Weekday in any clients that access the setting. But if we change it, that will break what's in the active Calendar PR. (The current setting is equivalent to what's in all the Ubuntu locales I've seen, which is 1 = Sunday.) But it would simplify the code needed in Calendar, since it could just see the setting and immediately short-circuit with that result. (Basically, this.week_start = (GLib.Weekday) setting; return;)

Yeah I think 1-7 starting with Monday seems like the best option since it matches Evolution and GLib.Weekday

Alright, changes added in. :)