Has anyone messed around with the watch face yet? If so, how? I’m not seeing anything about it in the git resources. I am learning as a go though, so it’s likely I’m missing something.
For anyone who has made changes to their watch face - what did you add or change about it?
Last time I looked, the SDK wiring for custom faces hadn’t really landed it. There’s a bunch of code bubbling beneath the surface but it hasn’t been exposed. Would love to hear differently, I’m keen on another area to customize!
Hi Chironaut, custom watch faces coming soon. We’re just implementing the watch face selector menu.
I have been building one for the past few days, as a Utility rather than a face, and some of what I hit is probably useful to whoever picks this up next. Feature set at a high level include:
Why a Utility. Packing it as APP_TYPE "Clockface" produced a package the kernel silently deleted on the next boot, leaving an empty directory. Filed as issue 295. The cause looks like the unconditional -glance_capable flag that fix/uapp-glance-capable-flag addresses: every .uapp claimed a glance interface, and the glance bit outranks the declared type, so a Clockface was taken for a glance and then judged malformed for carrying a GUI. So the type may already work once that lands, which would be good news for this thread.
What the hardware wants. The display board is UNAview_LS012, a reflective memory LCD, and once I understood it better, a few design decisions became obvious:
It holds its own pixels, so a static face is nearly free and there is no burn-in to design around. What costs power is how often you update it.
So do not put seconds on a face here. A ticking second hand is sixty times the panel traffic, all day, for something nobody needs on a clock. That is not to say that some use cases don’t genuinely need seconds, just that most cases probably don’t.
It is readable in daylight without any light behind it, so lighting the backlight on a daytime wrist raise buys nothing. Mine only lights between sunset and sunrise, worked out from the date and a GPS fix, since there is no ambient light sensor. The screen light wake is handled in three ways depending on the configuration choice, disabled, night (default) and enabled.
Numbers, in case they save anyone a night of measuring. ~165mAh cell, 4.20V full.
With my face open, the quietest draw I have measured is about 1mA, which is nearly seven days. Two things I got wrong and fixed: I held the GPS subscription until a fix arrived, which indoors may mean forever, and I left the sensor periods at the driver default of about two seconds when a face redrawing once a minute should ask for 60,000ms. Together those had the average sitting at 3mA, which is two days.
Two small things worth knowing. localtime_r does return local time, though nothing hands an app the offset as a number, so difference it against gmtime_r (thanks to shatter_poetry for narrowing this down). And a held L2 never reaches an app, because the firmware opens its media controls, so my three hold actions live on L1 at different durations with the screen naming each while the button is down.
The question I would most like answered, given the selector is being built: what will a face be expected to provide? Specifically whether it autostarts and stays resident, whether it is suspended when the display sleeps or notified some other way, and whether there is a redraw cadence the firmware expects rather than one an app chooses.
And one about buttons, since it decides how much of a face can be interactive. On the built-in face a single press of L1 opens the app list, so I assume a face does not own the short press. Does it receive button events at all, and does a held L1 reach it? If it does, the idea I would like to try is borrowing: a long press hands L1 and L2 to the face for a few seconds, with something on screen saying so, and a timeout hands them back. That way the system keeps the press a wearer depends on and a face can still be more than a picture. If holds do not reach a face either, that is worth knowing before anyone designs around them.
Happy to try things and report back; I have a face and a willingness to break it.
I just built my first UNA app today and it is a watch face. I used your tips (just pasted it in to the AI session) It shows the time and date, step count, battery %, and the sunrise or sunset in the current location (whichever comes next) and it also has a stopwatch feature. You press the top-right button once to start, again to stop, and again to clear it. It took me about 2 hours from start to finish and I used opencode with kimi. I didn’t write a single line of code.
Nice one Craig! Cool to hear abot the platforms you’re using. Would love to hear more.
I made a few enhancements after that post. Now when you press the top left button the sunrise/sunset time is replaced by the current altitude. I also cleaned up the UI. The battery indicator is now just a green dot until 50% and then it is yello until 25% and red under 25%.
Did you launch this as an app, or is this a customized clock face? I thought the custom face support was still forthcoming
I used smokey_foss’ advice and made it a utility for now - until watch faces are supported. See their post further back.
@lewis_una - any estimate on when we’ll be able to use the clockface type? I have two ready to go…
I have pushed my code to a GPL repo on github if anyone is interested: GitHub - cnakamoto/una-analog-watch-face: UNA watch analog watch face built as a utility for now · GitHub
