[settings] Idea: global "show date" option for clocks

[espruino-discuss2]

Posted at 2022-05-23 by rigrig

Lately I've been using a watchface where I patched out the date in my personal branch, for a cleaner look. (combined with the calendar widget)

I wonder if more people (would like to) hide the date? I'd create a PR making it a setting, but maybe it should be a global setting, instead of a lot of clocks ending up with duplicate settings code?

A downside would be the bunch of bug reports for a) clocks that don't use the setting (yet), and b) clocks that don't display the date in the first place...

[espruino-discuss2]

Posted at 2022-05-23 by HughB

I think the concept is good. Could be a show_date Y/N value.

Not sure how it would work for things like Pastel, Daisy and other clocks that have a status bar that cycles round different displays of information.

---

Posted at 2022-05-24 by @gfwilliams

I guess we could add that, yes - but obviously if only 2 clocks ever support it, it's going to be more of a confusion to new users than a help. There's also the question of what to do for clocks that already offer the option in their own settings.

Maybe it could be combined with porting a bunch of clocks over to using the ClockFace library and adding a note to the clock tutorials?

What if someone has two clock faces, one that they like a date on, one that they don't?

Maybe the best thing to do is to add some options to the ClockFace library (maybe like we have a buzz and buzz_menu library) so that it's trivial for clocks to implement their own settings page with options for date/etc?

---

Posted at 2022-05-25 by rigrig

Thanks for the feedback!
I figured it would be nicer to have a global setting instead of duplicate code in all clocks, but there are good reasons to keep it per clock.

Maybe it could be combined with porting a bunch of clocks over to using the ClockFace library

Yeah, something like that was my plan. Just putting it off a bit because a) porting clocks over just for the sake of porting feels like unnecessary churn, and b) I'd prefer thinking of more ClockFace features beforehand, instead of having to visit all those clocks again a few weeks later ;-)

---

Posted at 2022-05-25 by @gfwilliams

I'd prefer thinking of more ClockFace features beforehand

True :) Although in some ways, trying to port some clocks first will show you what features you need to make the porting process easy ;)

---

Posted at 2022-05-26 by Alessandro

A useful feature would be the loadWidget yes/no.

In a PR you said

But more importantly, I don't think we want clocks to disable the widgets, I think it should be a global setting. That way clocks can use Bangle.appRect to work either way, and users can decide if they want widgets independently from which clock they install.

but we have many Clocks that allow to show/hide the widgets (mosaic, lcars, time traveler clock, some analogue, ecc).

A global option would be great, like

• Settings → Widgets
  • Load & Show [X]
  • Load Only []
  • Don't Load

An app should read this option and regulate itself (better: should loadWidgets()/drawWidgets() handle the option? Pro: all apps will work automatically without further updates)

Meanwhile a loadWidgets option in ClockFace should be a good compromise - What do you say?

---

Posted at 2022-05-26 by @gfwilliams

I think for now, a loadWidgets in ClockFace is the best way to go if you really want to have it configurable, but it should be per-clock. The library could provide an easy way to add a 'settings' menu for that clock, that allowed configuration options - a bit like we do for beep and beep_menu libraries

There was a very similar conversation in a PR recently, but I forget which one:

I can totally imagine a case where someone has more than one clock face installed, and has one for daytime and one for night. In that case it'd make a lot of sense that the night-time one was configured without widgets, and the daytime one had them. But if it's a global setting then that's not really possible.

Also, someone will definitely toggle the setting and forget, and then complain that widgets have all disappeared :)

---

Posted at 2022-05-26 by @gfwilliams

Also, if you don't want widgets in all your apps why not just uninstall the widgets? Then it'll be much faster as well.

Or you could make an app (or just upload custom code) that sets Bangle.loadWidgets such that it doesn't load widgets, or maybe just loads them but sets area to "".

But I do wonder: Is this something people really want? I just feel that there are a million things that actually are real problems with Bangle.js at the moment that could be fixed, and I feel like this isn't really one of them. Clocks that can handle a mode where there aren't widgets normally have a menu option for it, and all the other ones generally don't handle it.

---

Posted at 2022-05-26 by Alessandro

I think for now, a loadWidgets in ClockFace is the best way to go if you really want to have it configurable, but it should be per-clock.

Ok!

@rigrig - do you mind if I reopen my PR?

I can totally imagine a case where someone has more than one clock face installed, and has one for daytime and one for night. In that case it'd make a lot of sense that the night-time one was configured without widgets, and the daytime one had them. But if it's a global setting then that's not really possible.

Yup, it makes sense.

Also, someone will definitely toggle the setting and forget, and then complain that widgets have all disappeared :)

haha, true :-D

---

Posted at 2022-05-26 by Alessandro

Also, if you don't want widgets in all your apps why not just uninstall the widgets? Then it'll be much faster as well.

I just noticed I forgot to add some details. I was thinking about the hideable widgets bar. I'd like to be able to hide the widgets from all the apps (clock face included) so the apps could use 100% of the screen but I'd like to temporarily display the widgets with a swipe in the clock face (like android control center/notifications)

But I do wonder: Is this something people really want?

I can only speak for myself but I think it is a shared thought: users want a better user experience. The Bangle is a wonderful device but some things feel unpolished and barebones. A trivial example: labels capitalization. Some labels are all lowercase, some Full Camel Case, some Another case variant etc.

IMHO the Bangle lacks some consistency here and there and I'd like to help to improve it (I love the bangle, this is also the first open source project I actively participate!) (this is one of the main reasons I rewrote the alarms app)

Anyway kudos to Gordon for everything!

---

Posted at 2022-05-26 by @gfwilliams

I'd like to temporarily display the widgets

Then you want this issue :) espruino/BangleApps#1466

A trivial example: labels capitalization. Some labels are all lowercase, some Full Camel Case, some Another case variant etc.

PRs for this would be great. It's unfortunately just a side-effect of having a bunch of different people contributing, all with different ideas of what it should be :)

---

Posted at 2022-05-27 by rigrig

@alessandro: instead of letting the app specify loadWidgets directly, I think it was better to make it support settings in general, and have "magic" loadWidgets setting. That way you only need to add it to your settings, and the library will handle it. (instead of your code needing to read the settings and pass them on to the library)

I created a PR: basically you can specify a settingsFile, and it is loaded directly into your clock.

If you have a loadWidgets setting, changing it to false prevents widgets from being loaded.

---

Posted at 2022-05-27 by Alessandro

Agree, your solution is much better.

---

What do you think about a variable "precision"? Eg 60 seconds when Bangle is locked and 1 second when unlocked? (customizable)

My use case is that on my custom clock (using Clock Face + Layout) I want to show the next timer. I update the residual time every minute (eg. ~10m, ~5m, ~2m etc.) but when timer is < 1m I'd want to update every second.

Is a variable precision something we could add to the module? Maybe the return value of draw()/update() will be set as next precision? If undefined the default precision will be used.

What do you think?

---

Posted at 2022-05-28 by rigrig

The module sets a new timeout for the current precision after every update, so simply changing this.precision inside draw/update should work.

---

Posted at 2022-05-28 by Alessandro

Hi!
I already tried to update this.precision but it does not work :(

  precision: 60,
  ...
  update: (time, changed) => {
    console.log("test: " + this.precision) <-- the first time this.precision is undefined
    this.precision = 1
}
...

---

Posted at 2022-05-28 by rigrig

Ah, that's because you're using an arrow function, this is only bound to "real" functions:

update: function(time, changed) {
         this.precision = 1; // this works
}

---

Posted at 2022-05-28 by Alessandro

aaaahn, understood! I'm not a Javascript expert, I thought they were the same thing!