PrimeTime Watchface

[tituscmd]

Hey all!

This PR introduces a new watch face I recently made. The design is based on the existing Digital watch face. Whether this should replace the current Digital face or live alongside it, I don’t have a strong preference either way.

This watch face uses a new font I added called Karnivore. It’s a free TTF font, so it should be fine licensing-wise—but feel free to flag anything I might’ve missed.

One neat addition is that it shows the current song playing directly on the face, below the line showing the day of the week and the date. Though it has to be said that its color might be a little bit dark on the black background, but I thought it looked best like that regardless.

I also styled the heart rate and step count icons/values to match the colors used in the InfiniLink app because I thought they looked nice(r) :)

The day of the week is shown in sentence case (Fri), instead of all caps like on the Digital face. The date is in DD.MM.YYYY format. I personally prefer using periods and leading zeroes for single-digit months.

The battery percentage is shown at the top. Right now it’s hard-coded, but this can of course be updated if PR #1959 is merged.

I think that covers everything! Hope you like it 🙂

[github-actions]

Build size and comparison to main:

Section	Size	Difference
text	381736B	2532B
data	944B	0B
bss	22536B	0B

Run in InfiniEmu

[vkareh]

Looks great!

I particularly like the current song on the watch face - whether this makes it in or not, any chance we can add the current song to the Digital watch face as well? I would totally use that feature.

[tituscmd]

Alright, I've gotten all the checks to pass now. So sorry for having so many commits now!

[vkareh]

So sorry for having so many commits now!

You can always run git rebase -i HEAD~15 (since you have 15 commits) and mark all those extra commits as fixup or squash. That'll effectively merge all those commits into a single one that then you can git push --force here to replace.

[tituscmd]

So sorry for having so many commits now!

You can always run git rebase -i HEAD~15 (since you have 15 commits) and mark all those extra commits as fixup or squash. That'll effectively merge all those commits into a single one that then you can git push --force here to replace.

You are my hero!! 😄
Thank you so much, looks much better already :D

[tituscmd]

What do you guys think of mixing Prime and PineTime into PrimeTime? 😆

[mark9064]

Looks super cool! I think it's different enough to the Digital face that it should be its own one. Could you move the font to the external flash? That should make the watchface much lighter size wise

[tituscmd]

I have no idea how I've done this, but I've accidentally added A LOT of unnecessary files.

[mark9064]

Looks like your tree isn't doing so good 😅
It's always a good idea to look at the diff you have staged before committing, because you can check you haven't committed anything you don't want to. Not sure if you ever come across this, but git commit -a and similar are worth avoiding as otherwise you can get nasty surprises.
E.g this commit 6608cf9 adds 50,000 lines of text.

Also when you rebase, it's worth thinking about what you're rebasing onto. I'd usually rebase onto the main branch, as that means your PR is up to date with main after your rebase. Make sure you pull the main branch first though

[tituscmd]

I think I've accidentally done a git add . which added all of my .orig files. Can I revert commit 6608cf9 to fix this?

[mark9064]

I have no idea how I've done this, but I've accidentally added A LOT of unnecessary files.

OK, so the first thing to do is make a backup of the branch so you can go back in case something goes wrong after.

Here you've got a few options. Start an interactive rebase onto main.

You could drop (i.e just remove the line from the list of commits to apply) 6608cf9 and then remake the change again after.

Or, you could choose to edit 6608cf9 in the rebase queue. Once the rebase has stopped at the commit, undo the commit (git reset HEAD~) and then restage the changes you actually want and commit those. Then you can continue the rebase.

When you do an (interactive) rebase, each commit gets replayed onto the base you choose. E.g. if you do git rebase -i main every commit in your branch will be replayed on top of a fresh copy of the main branch. If there are conflicts when applying a commit, the rebase will stop and you'll be asked to resolve them. Once you've resolved them, you can continue the rebase. Also, the rebase will stop at every commit you're editing so you can make the changes you want. Rebasing is very powerful as it allows you to completely rewrite the history. You can base commits off a different branch, re-order commits, edit them, bring in new commits from other branches etc. all at once! But it also means it's very easy to do something wrong. So if you mess something up, git rebase --abort is your friend and if you only realise after the rebase finishes that's what the backup branch is for :)

[tituscmd]

I have no idea how I've done this, but I've accidentally added A LOT of unnecessary files.

OK, so the first thing to do is make a backup of the branch so you can go back in case something goes wrong after.

Here you've got a few options. Start an interactive rebase onto main.

You could drop (i.e just remove the line from the list of commits to apply) 6608cf9 and then remake the change again after.

Or, you could choose to edit 6608cf9 in the rebase queue. Once the rebase has stopped at the commit, undo the commit (git reset HEAD~) and then restage the changes you actually want and commit those. Then you can continue the rebase.

When you do an (interactive) rebase, each commit gets replayed onto the base you choose. E.g. if you do git rebase -i main every commit in your branch will be replayed on top of a fresh copy of the main branch. If there are conflicts when applying a commit, the rebase will stop and you'll be asked to resolve them. Once you've resolved them, you can continue the rebase. Also, the rebase will stop at every commit you're editing so you can make the changes you want. Rebasing is very powerful as it allows you to completely rewrite the history. You can base commits off a different branch, re-order commits, edit them, bring in new commits from other branches etc. all at once! But it also means it's very easy to do something wrong. So if you mess something up, git rebase --abort is your friend and if you only realise after the rebase finishes that's what the backup branch is for :)

While this sounds very smart and probably would have been the safer way to do it by far, I've somehow managed to just revert the commit and remove the rest by hand. And miraculously that worked and didn't absolutely break everything.

I apologize for the very unprofessional work in this PR... 🥲

[mark9064]

No worries, whatever works 😄 Learning rebasing might be worth it though. Having a nice commit history makes review faster but it's not a must, most of the time I look at the total diff of the PR anyway. Changes look solid and resource usage looks better now :) I'd like to review this soon but will have to see time wise

[tituscmd]

No worries, whatever works 😄 Learning rebasing might be worth it though. Having a nice commit history makes review faster but it's not a must, most of the time I look at the total diff of the PR anyway. Changes look solid and resource usage looks better now :) I'd like to review this soon but will have to see time wise

Yeah, I'll definitely learn rebasing the next time around!