that this might actually be, might actually be for the podcast. So I did run a test this time to make
sure I don't mess up the recording again. And so I set myself a timer half an hour and recorded
myself just, you know, as I was working. And of course I can set a timer and immediately forget
about it. So every Monday I do system maintenance and stuff, and I set a three or five minute timer
for each machine to check it after it's been rebooted. And you wouldn't believe how often
that timer goes off and I think, what's that about? Yeah, what on earth do I need to do?
Within three minutes, I forget what this timer was about. I'm not in the kitchen,
so there's nothing obvious heating up or something that needs attention. And I just don't understand
what's going on. Well, welcome everybody to the Over 50s podcast. Well, it started sooner than
that but yes yeah I'm not I'm not I'm not actually quite 50 yet I'm 14 oh all right all right well
you've you've segmented us nicely there um so anyway you can imagine how long it took for me
to completely forget about this recording and then when the timer went off I stared at the
at the watch and then but because it was 30 minutes that I made the connection 30 minutes
was weirdly very unusual time for a timer then ah right yeah you had this recording running
What you haven't mentioned is why you were doing this. Well, do we really need to
go into this? So well let's let's talk about it. We had a bit of a week last
week. We had a serious issue with the package index itself and we also had a
podcast recording last week and when I received the Sven's audio file it was
about three quarters missing with just complete silence and there must have been maybe a loose
connection or something like that from Sone's microphone and so I asked him to do some testing
and that was his half an hour microphone record that he was just referring to.
Yeah exactly and this actually ties nicely back to the remainder of my story because when I was
listening back to this I'm still working on this problem. I'm still picking up the pieces from what
went wrong last week. I listened back and there are these sighs in the recording like,
"Oh, why is this not working? I completely forgot the microphone. It is hilarious to listen back to
this. Someone's suffering at their desk in agony over stuff. Oh God, I'm just glad this isn't
running the whole time." Well, so that's the thing. We are actually surrounded in modern life by
tens of microphones. I don't know how many microphones there are in my house, but there
are a lot. Yeah, I wonder how many are live. Yeah, exactly. And I don't want to hear all
the exasperation that I say throughout an average day.
I'm actually becoming more conscious of this because I work here with the window wide open.
I can often hear the neighbors talking two floors down on their balcony. I've started
of reining myself in a bit because I do sometimes when stuff doesn't go right I
do tend to curse a bit and I thought I need to dial it back. That's really
interesting I can I hear my neighbor there through the wall. Sometimes it needs
to be done it's like hitting return harder has an effect for sure. Yeah should
we should we briefly talk about what actually happened? Yeah so let's talk
about the problem.
Yeah.
So in broad strokes, we released an update last week, early last week.
I think it was Monday afternoon.
Um, and the repercussions only became obvious later that evening.
And long story short, what happened?
We lost about half of our versions and a version in our system is a.
Get reference essentially.
So we have one, uh, branch that we're tracking the main branch, default
branch of a repository and then we're tracking a reference, a version for every release that package
has. And you can imagine there's a number of them. We have a bit over 6,000 packages and we have
100,000 versions that we're tracking in the index. And we lost, I think like 45,000 before we noticed
what was happening and why it was happening and pulled the plug. And the problem was there was a
delay for us to notice, a significant delay due to how the bug manifested itself between us
actually having a chance to see that we lost the revisions?
Yeah, without going into like real detail about it, it's kind of a complicated
situation where it wasn't... we have these analysis cycles where we'll run past all the packages
looking for changes and then back round again looking for changes and back round again, and
And they take about, is it about three hours
that it takes to run past that?
Last time I checked, something like that.
- One complete cycle takes around three hours
and then it goes back to the start.
- Right, and the bug only manifested
in the second set of analysis
after this bad release was deployed.
And so you're in that worst of all situations
where the release gets deployed, everything seems fine,
and then at some point later, everything goes to, yeah.
And the thing is, I stopped stuff when I initially saw the problem and then I rolled back and I
didn't see a change. And I didn't see the change because the problem didn't manifest itself
immediately. And then I rolled forward again. And that cost us revisions because had I stopped there
and given that more time, that would have saved us. But long story short, we lost the revisions.
that's actually not the end of the world. The revisions come back quickly within one analysis
cycle. We're all back on the revisions. What we also lost, unfortunately, were all the builds that
we have attached to a version. And those are the compatibility builds that we run, that we kick off
for each package across all the platforms and all the Swift versions that we're tracking, which is,
I think 30-ish per version.
32 I think, yeah.
Yeah, so you can imagine that's a lot of builds that we now have to catch up on.
We're actually still in the process, tail end of the process.
We decided last week not to replay a backup.
We do run backups of the database, but that was also unfortunate because we were so deep
in trying to figure out what was going wrong.
we didn't actually, or I didn't actually think through how complex a database rollback is.
And it's actually a lot easier than I thought at the time. I did not stop and think that's
a bit unfortunate because we could have very easily played that database back
and have avoided doing the builds. Yeah. And that's the thing, like in these situations where
you have to make a decision and you make that decision under pressure and while the world is
falling around you, it's sometimes difficult to make the best decision in those situations.
I mean, the other thing that happened last week,
completely outside of this tech stuff is I played a paddle game. Paddle is a kind of a tennis game.
They play here in the South of France. And I hurt my back. I got, did you call it lumbago in English?
Sure, yeah.
Lumbago in French, yeah. And I was completely wrecked. I couldn't move,
couldn't even sit the first couple of days.
since Wednesday afternoon. That certainly didn't help. And it's really, really hard
to think straight in these circumstances. So last week I deployed that release that
nuked half of our versions. I ruined our podcast recording. I ruined my back. I hope this week's
going to go better.
But apart from that, how was the rest of the play? Yeah.
Yeah, just going great. It's just going great.
So in slightly more positive news, we have also been working on...so I think we mentioned
this a few months ago actually, that we were putting in a pull request on the Swift.org
website repository to add a packages page on that site to start to bring in some of
the Swift package index data onto the Swift website
to help kind of showcase and expand the package ecosystem
and what people see on that site.
So we're getting a little bit closer now to merging that.
And I thought it might just be interesting to run through
how we get the data into that page.
And there's the technical side of it,
which is physically, or not physically,
but technically, how do we query the database,
query the API, put together the right file,
submit it as a pull request,
and that will be the technical side of updating it,
but actually that's not very interesting.
The more interesting bit, I think,
is how do we pick the packages that are on that page?
So if you haven't seen the page demo yet,
we did link to it last time,
but we'll pop a link in the show notes again
to the, we have a staging site for it set up.
And that staging site has a little bit of a preamble
about what packages are and what the Swift package index is
and that kind of thing.
But then it quite quickly goes into a set of lists
of packages.
And some of those lists come straight
from the package index database.
So for example, there are categories in there.
So there's a list of six networking packages,
six packages that might help with testing
and that kind of thing.
Those, the sources of that are fairly straightforward
in terms of that's just the top six search results
that come off the Swift Package Index site.
So if you did that same search on the package index,
you'd get the same six packages
as we're currently gonna be showing on swift.org.
Then we have a couple of lists that are things like,
for example, I think one of them at the moment is
packages that have macros in them.
So kind of highlights macros are a new feature in Swift 5.9.
And so let's highlight some packages that use that feature
on Swift.org so that people can see them.
But again, the results that come in are just,
if you did that search on Swift package index,
it would be in exactly that order.
But actually the top category on the list is probably,
I think, the most interesting one.
And it's called, or we've called it the community showcase.
And this is a manually curated set of packages.
And I think it's interesting to talk about
where that manual curation happens,
how it will happen going forward,
who's responsible for it, that kind of thing.
We're about to make a post on the Swift forums about this.
So this is slightly premature,
but I think it's worth talking about here too.
So the whole idea behind the Community Showcase
is that it shouldn't try and be like a best of the best
packages or something like that,
but whatever packages are being discussed in the community.
So whether that be on a podcast like this, for example,
where we're gonna talk about some community packages later,
or any other podcast from the community,
or blogs or newsletters or something like that.
So what packages are being highlighted?
What packages are people talking about?
And the only rule we've made actually
is that nomination of a package to go in this showcase
should be, you should nominate somebody else's package
rather than your own.
So for example, when we do the community packages
at the end of this podcast,
we don't link to our own packages.
We talk about other people's packages
and other podcasts and newsletters and things like that
also doing that. So that's the rough criteria and we will collect nominations
from people who run that kind of, you know, podcasts and blogs and things like
that via the Swift forums. But then of course those nominations have to go
through and six of those - let's say there are more than six nominations - we have
somebody has to make a choice of, you know, which actual packages go onto that
page. And this is where the Swift website workgroup initially comes in. So I'm a
member of the Swift website workgroup and we do various bits of development
and try to push the Swift website forward a little bit. And we do several
bits of work towards kind of making the Swift website a little bit better and
kind of pushing things forward in terms of the content on Swift.org. But also the
Swift website workgroup is going to be the group which is responsible for
initially curating which of these community packages make it onto this
page. And this is going to happen on a fairly regular schedule. So we're
thinking it'll either be every two weeks or maybe every month that these get
updated, something like that. And so there'll be a series of kind of phases
to it. We'll collect some nominations from people who run these community
resources and then the work group will make a decision on which one goes in and
then we'll finally update the Swift website via the pull request that we
talked about earlier. And so we hope that that is a reasonable way to
organize this. It's certainly... we don't want to make the decisions. The Swift
website workgroup is you know managed by Apple and actually the Swift website
workgroup is only temporarily going to be responsible for this. There was a
blog post I think again like a couple of months ago where the Swift
project announced that there would be some new workgroups coming and one of
those work groups is the ecosystem work group. And one of the things that that
work group is going to be responsible for is the package ecosystem. And so I
think the plan eventually will be to have that work group make this decision
rather than the website work group. But what we were very keen for it not to be
was us. We don't want to make this decision, do we? Yeah, I really liked what
you said at the start that this ecosystem category is not so much about
the best package or quality as a metric, but what's interesting and what's being talked about.
And I think this is sometimes reflected also in our choices where we pick stuff that's just
interesting because I think there's more than one reason to look at packages. It can be inspirational,
it can be educational, it can be fun. It can be something that someone who's learning the language
or learning about packages is just trying.
And I think all of these should get some space.
It shouldn't just be about, you know,
what absolutely bulletproof, perfectly maintained package
do I need for my networking?
Of course, that's one of the reasons
why you need a package index or package recommendations,
but it's about more than that.
I mean, a lot of this is educational.
I look at packages that I know I won't have any use for,
but that I just find interesting, you know,
you know, in the way they present themselves, how they do things, what their documentation looks
like, the readme, that sort of stuff. It's often interesting aspects of the language that I don't
know well that I want to learn about a bit. Or just to observe someone taking their first steps
in publishing a package. That's also interesting and fun to see, and I know how that starts.
because we've all started there, right? We've all had our first package, our first pull request
something up and it can be really daunting and seeing that happen and maybe help it along a bit
with a pull request yourself if you notice something can be really nice and welcoming.
And that's part of why we called it the showcase. That word showcase is literally what this is.
and we want to highlight brand new packages there
that maybe haven't had that kind of battle testing,
but they may be interesting.
And I think it's a really positive thing
that Apple wants to showcase that kind of package
on the official website as well.
And that shows that it's not just about,
it's not all about, well, you can't get on this page
unless you absolutely make the best package there is,
because what does that even mean? (laughs)
But this is a look at the ecosystem.
This is, you know, the Swift 6,500 packages,
something like that.
But there's all sorts of interesting stuff
going on inside that thousands of packages.
- Yeah, definitely.
- So the next thing that will happen with that
is that we will make a post to the Swift forums
and the purpose of that post is obviously
to lay out our plans a little bit,
but also to ask for the primary purpose
is to ask for feedback.
So if you have any feedback on this idea,
nothing is too late.
Yes, we have a prototype up and we have been through,
like if you go to the pull request,
you'll see lots of reviews there and tweaks
and we have been moving it forward,
but this is not,
I think the stage that I would consider this at is,
We'd be happy to merge this given no feedback comes from the community, but that feedback
from the community is absolutely within scope to make changes to what we're proposing.
Yeah. Right. We got any other news?
I don't think I have any other news. So should we do some packages?
Actually, one thing we could briefly talk about, which was in our messed up recording,
but that's the first round of Dependabot updates that we saw against one of our projects in
the Swift package index.
So we mentioned this three weeks ago now that there's a new feature on GitHub.
If you have a Swift project, they now run a dependency check against your repository.
believe this is currently only happening if you have a package.resolved checked in,
because that's the underlying information they use to discover whether any of your packages that
you're using as a dependency have any issues. And if that is the case, and it's not even an opt-in
that happens automatically, it will highlight this in a section on GitHub. I'm not sure what
the panel actually is, we'll add a link to the show notes. This actually happened to us. So one
of our packages that we don't update frequently was running an old version of Swift Neo, which had
some updates that fix CVEs. And those were highlighted and alerted us to that fact. And then
we ran a package update to update it to the latest version. So that's really nice. Again, we'll add a
link to the show notes to show what that looks like. And I believe package
resolved being checked in is a requirement, but that's probably the case
for most packages. So yeah, there you go. Yeah, I think it's really nice
that this is on by default for repositories that have that file. I
think you can actually go a step further if you want to, and this is not on by
default, but you can go in and say "also please raise a pull request" and the
dependabot will, if it finds a vulnerability, it will then take your
package.swift and package.result file and upgrade both of them if necessary to
a version that no longer has that. So you can have it literally
open that pull request and all you have to do is merge that to get the new
dependency in there. We take a slightly different - I think we mentioned this
again three weeks ago - we take a slightly different approach to that in that we
have a script that runs every week that says here are you out all of your
out-of-date dependencies so we're not gonna have that automated dependable one
on but we we do love this this feature of the notifications yeah yeah that's
really great okay should we should we do some packages join a kick us off fun I
shall do so my first package my first pick is called xcbeautify by Tuist
I absolutely love this. We've been using xcbeautify for quite a while in the Swift package index itself, not only in the project.
So what I should explain what it does. xcbeautify is a executable, a command line executable that you can pipe your Xcode build and Swift build output and test runs through.
And it beautifies the output.
If you've seen what XCTest failures look like or build failures look like, it can get a
bit messy, XED beautify.
Makes that nice on the command line.
It even adds ANSI colors, so you get nice colored output.
Works also in CI as a nice output there.
We've been using that for a while.
Not only in our CI, we've also run the Xcode builds through Xe-Beautify of our build output
that we generate.
So if you go to a package page and click through to the builds and then click on any of the
Xcode builds, you know, like the iOS watchOS to be OS builds, that output there is run
through Xe-Beautify to make it look nicer, make it more digestible because it can get
really noisy.
Now a new feature they added in version 0.21 and I think now they're also there even on
1.0.0 so if you go to the latest major version you'll effectively have this.
They added a new GitHub actions renderer which doesn't give you quite that ANSI colored output
it but it generates an output that is picked up by GitHub to surface test errors in the
GitHub Action UI. And that is really, really nice because in the package index, we have
hundreds of tests and if there's a failure, it's really hard to find them because we have
our log output is thousands of lines.
So you have to scroll a lot to find the error.
What this does, it shows you the not only the error output, you know, what the failure
was with the expected and actual values.
It also gives you a click through to the source of the test so you can read all the
context around it. And this is on the GitHub Action overview and it's really nice. I think
it also inlines into pull requests alongside the code there. It's fantastic. I just absolutely
love it because in the past I really dreaded when there was a CI failure. I often just
ran rerun the tests locally because I couldn't be bothered scrolling through thousands of
lines of tests. I thought I went, I'm just going to get a coffee, run the tests and see
what's happening and now it's just all there. You can click through and see the results
straight away. Absolutely brilliant.
- I love this feature. I think it's such a time saver. I was in exactly the same boat
as you if I got a CI test. My first port of call would be to run the tests locally again,
and only if the test passed locally would I start to look through that log file.
- First port of call was to shout profanities and run it locally.
right yeah shout to my neighbor kid here that's right so yes it's a it's a great
step forward for it and I think I'm just happy that we've we have this on our
project now it's saving time already yeah absolutely okay my first package is
by Vikram Kriplini and it's SwiftUI Shimmer so this is a bit of a package
that a package that has a little bit of nostalgia to it but also is is still
very much useful today. Do you remember when the original iPhone came out and it had no
passcode on the original iPhone? Why would you possibly need to protect? Yeah, it's
wild that they didn't have a passcode on it. Because there was nothing to protect, right? It had
almost no information on it and we lived - it was a different time, Sven. It was a
- I did lose it.
I lost an original iPhone without any passcode and stuff.
I changed some, I mean, obviously changed my,
I'm not even sure, was it even iCloud at the time,
my password, but--
- No, no iCloud.
- Unimaginable these days.
- Yeah.
Anyway, so what it did have instead of a passcode
was a beautiful bit of UI where it said slide to unlock
and the text of the slide to unlock,
there was a kind of shimmer effect
that went from left to right across the text
of a little at an angle,
as if the light was catching it.
And it was to indicate,
because don't forget touch screens were fairly primitive
at the time, this was to encourage you
to interact with that element.
And it was a lovely bit of UI,
I think one of the most beautiful bits
of the first iPhone.
So SwiftUI Shimmer is a package that brings that
to all of the modern platforms.
It's actually been around for a couple of years now.
But the reason it caught my eye this week
was because you can add a shimmering slide to unlock screen
on your Vision OS app with this,
with this SwiftUI modifier in this package.
And I think we should encourage everybody
to add slide to unlock to their Vision OS app.
- And then you slide across it with your eyes.
- That's right, you just look from left to right
and the application unlocks.
Actually, I don't know,
this is a little potential rabbit hole
that we're going around here,
but I don't know how,
how does VisionOS do the authentication?
How do you, it must have a class code or a lock or something.
Is there a biometric?
- No, it doesn't, it scans your iris, I think.
- It scans your iris, okay.
- I'm not sure what the name of it is.
There's a marketing name for it.
It's not eye lock or something,
but it is something related to the eye.
But I'm pretty sure it does an eye-risk scan.
Unless I'm fantasizing now,
I'm pretty sure that's what's happening.
- I'm sure I knew at one point,
but I've already forgotten.
So we'll have to see when the device gets here.
Anyway, that's SwiftUI Shimmer by Vikram Kripalini.
- Nice, really nice.
I love that.
It was so, so powerful in what it communicated
and how well it did that.
It's just amazing, yeah.
Definitely lost something there.
- There were several bits of breakthrough UI
with that first iPhone drop.
It's a very rare event that you can have something
that pushes UI forward so far in one moment.
There was a time before the iPhone
and there was a time after the iPhone.
- Yeah, scrolling definitely is.
You know how it continues when you flick it
and the rubber banding at the edges
and I think those are the key things,
the key inventions around these touch screens
that were transformative.
- Well, and the other thing was multi-touch.
- That really was so powerful.
I watched a kid, like in the early days of the iPhone,
toddler pick up an iPhone looking at pictures
and pinching and zooming naturally.
That tells you everything you need to know
about that interaction, that it works.
If a child can pick it up and just naturally do it.
It was so, that was astounding to watch that happen,
watch that, observe that interaction.
- Back to the Over 50s podcast.
I'm actually quite disappointed
when I pick up a physical piece of paper
and I can't do it on that because I need it.
- All right.
This does not zoom, yeah.
- Okay, exactly, nothing's in it.
- My next package is called Swift Prompt
by Michael O'Brien and Michael O'Brien.
I'm actually going to make that same joke as last week
because it's new to all the others, but not today.
We have this nice little bug in our website
where we spell out the author name twice
and that's because I presume that author has commits
with different email addresses and we don't,
at the moment, de-duplicate them.
So--
we figured out what it was, isn't it?
- Oh, right, right.
- The two different apostrophes.
- Oh yes, I figured it out on the podcast.
So there's the apostrophe exactly one is the-
- We did, we figured it out live on our failed recording.
- Well, we had some successes,
but they just never see the light of day.
(laughs)
Right, so the package is a command line interface package
for text input and option picker prompts.
And it's absolutely beautiful.
You need to look at the readme of the package.
Um, what that looks like.
I, I just want to run off and write a command line tool that, that uses it.
It looks really nice is using these, um, Unicode, um, what you call them glyphs.
There's a little screencast on the, um, on the readme to create menus that you can
arrow through and has a password prompt as well, where it hides your inputs.
Uh, absolutely beautiful.
it's if you have any sort of input that you're capturing
for a script, use this, it looks really fantastic.
Yeah, it's a small little package.
That's what it does.
It apparently does it really well.
It's called SwiftPrompt and is by Michael O'Brien.
- So there's always a decision to make
with this kind of situation
where you're writing a command line tool,
you need some input.
And one way is to go down the pass everything in
as an argument, which is the Swift argument parser
way to do it.
And this is a nice alternative to that,
where you might pass some things in as arguments,
but then you want to have some interactivity.
So maybe you want the user to make a choice
between a few known options,
or maybe that one choice depends on another choice,
and that's hard to get right
with just purely arguments.
And so I can see good uses for this,
where for slightly more complex command line tools.
- Yeah, absolutely.
Or because if you pass stuff in through the command line,
it is visible.
There's ways that can be seen
if you're on a multi-user system, for instance.
So that might be a reason to use it.
That's direct input into the process
that isn't telegraphed on as a command line input
or an environment variable.
- Exactly.
My second package is called sf2lib by Brad House.
And this is not only a new package to me,
but the content or the purpose of the package
was also new to me.
So this is a package that passes and renders sound fonts.
Have you ever heard of sound fonts before?
- Sound fonts.
Oh, is that like an accessibility feature
where it has little, oh no, I was thinking of sparklines.
- That would be a great idea, but it's not that, no.
(laughs)
A sound font is a, well, it's pretty much exactly
what you think it is.
It is the equivalent of a font,
but with musical or sound samples,
any kind of sound samples.
So it is a file format that holds both MIDI map information,
so the MIDI notes mapping to certain sample files,
but also it contains the sample files as well.
So for example, you could create a sound font of a piano
and have all the different recordings of all the keys
at various different velocities and things like that,
and then distribute it as one file,
which is here is the piano sound font,
and people could render that and play back
the right samples at the right time based on MIDI input.
So I love the package index because not only does it teach me about new packages, but it
teaches me about whole new things like this because I haven't come across sound fonts
at all. And it's based on a C++ library behind the scenes and the SF2lib I believe is a wrapper
that supports iOS, macOS, TBS. And yeah, it's not something I'm going to use in the next
few weeks or potentially ever but I found it really interesting to learn
about this. Nice, interesting. So how would you actually use it? What's the... is
that to create those sound files or what's the... what does the package... No, it's
not to create them, it is to parsing and rendering of them. So by rendering I
presume it means playback. Yeah, alright, interesting. It does mention that it
depends on DSP and audio classes from an AUV3 support package. So I think
there's almost certainly playback functionality in there.
All right, my third pick is called Swift Async Assert by Angoo Software. And this
is a really nice convenience package when you're dealing with tests of async
functions, because when you do that, you may have noticed that you, for instance, if you try and
write a test XCT_ASSERT= what you put in there can't be async because it doesn't have an async
context. So you'd need to either grab the value first by, you know, running a let temp variable
equals a weight on your thing and then stick it in there. That's obviously a workaround or you
have to write your own wrapper function that does that for you, which isn't hard, obviously.
I mean, that's an easy thing to add. We've actually done that in a couple of cases in
the package index in our tests. This nice little library does that for you. It packages all those
up, does that for all the XCT assert variants out there, so you don't need to cover them all
yourself or start with a few and then always be annoyed when a new one pops up that you haven't
covered yet because that's the situation we are in. We got a fair few, but as soon as we need
exit assert equals with accuracy, we'll have to go back and add that one. So it's really nice to
have this all packaged up. And it's one of those packages that you can, that's easy to adopt,
right? Because this you can do yourself easily or add it if upstream it's missing, you can open a
and a pull request and added.
I love these kinds of packages.
They're easy to depend on because it's something
you can absolutely do yourself,
but it's a time saver that you don't have to.
So yeah, Swift Async Assert by Angoo Software.
- That's great.
My final package this week is a package called Bezel Kit
by Mark Battistella.
And I love how minimal this package is.
It probably has more than this,
but the main functionality of this package is one method.
(laughs)
And it's not even an instance method, it's a static method.
So how good is that, right?
So what does it do?
It tells you how big and what shape the corners are
on whatever device it is running on.
So for example, on an iPhone,
you have the rounded corners at the screen edge
because none of the corners are square
on the iPhone screen.
And they're not even standard corners,
they're squircle corners.
So I forget the mathematical name,
but it's a slightly--
- Squircle.
- It's not a perfect, it's a squircle,
yeah, exactly, it's a squircle.
And the purpose of this package is that if you have some UI
in your application that wants to inset
from the edge of the screen by a certain amount,
it's quite difficult to get the radius of your squirkels
to match the radius of the device squirkels
because not only do you need to make it a squircle,
which of course there are APIs to do that,
but as you inset from the edge,
the size of your corner radius is going to be different
than the size of the corner radius on the device
because your inset, like it's not the same size.
And so what this will do is it will tell you,
it will basically give you the device bezel size
and make it really easy for you to draw perfect squirkels
inside the inset of whatever device it is you're on.
nice. Yeah, the readme, I'm just looking at it, lays that out nicely and gives the examples what
that looks like as a nice... Better than I did.
Yeah. Well, I mean, it has the advantage of being able to show a picture, which you
kind of have to try and paint with your words. But yeah, it looks really nice. I'm wondering,
you probably don't know if, does it have to sort of hard code and figure this out? So if something
new came out this September with a new geometry. Does it actually use the, you know, the insets
that it knows about to do that automatically or would it need to? It's a really great question.
Ah well, maybe we'll know by next time. So that's Bezel Kit by Mark Battistella. There we go, so
we will be back in two weeks or potentially next week if the recording has failed again.
We will find out in about five minutes whether we'll be back next week or the week after.
But hopefully with a perfect recording we'll be back in two weeks
time to talk more packages and we will see you there. I hope so much that we'll
see you in two weeks. Bye bye. Me too. Bye bye.