<sharkdp>
I realize it's not necessarily a UX improvement, but I find it much cleaner conceptually... in terms of language design (not having strings on the right hand side of the conversion operator)
<sharkdp>
We could still think about adding the old behavior back as syntactic sugar... but implementation-wise, I'd prefer the new approach
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
sharkdp has quit [Remote host closed the connection]
<triallax>
preparing an update for the chimera port
<triallax>
hmm, the 1.10 package is quite a bit bigger than before
<triallax>
was 3868 KiB, now is 5492 KiB
<triallax>
probably has something to do with datetime
<sharkdp>
Pretty sure it's the embedded tz database :-)
<triallax>
ah, right
<triallax>
have we found out there's no way to use the database shipped with the system?
<sharkdp>
I haven't checked
<sharkdp>
Something we can look into. Also: deferred loading of the tz database in the web version would be really nice. numbat.dev loads noticeably slower since datetime support
<triallax>
it'd also be nice because then the distro's (hopefully) up to date tzdata can be used
<triallax>
instead of waiting on numbat and chrono_tz updates
<triallax>
and of course make the package smaller, but that's not so important for distro packages
<triallax>
okay, the icon looks horrible in gnome
<triallax>
not detailed enough
<triallax>
i only tested with numbat.png and not with 196x196 and the others :/
<triallax>
oh neat, i thought we did it for each release
<triallax>
do you think it might be confusing to have both assets/numbat.{svg,png}?
<sharkdp>
I'm fine with adding both
<triallax>
the problem is that assets/numbat.png already exists
<triallax>
but it's the other logo
<sharkdp>
oh. feel free to remove those old logos
<triallax>
and i replace it with a rasterized png of the svg icon?
<sharkdp>
sounds good
* triallax
fires up inkscape
<triallax>
oh i could generate the different icon sizes now
<triallax>
with imagemagick actually, no need for inkscape
<sharkdp>
I believe you can also use inkscape on the command line. I'm not sure I would trust imagemagick to generate faithful SVG exports(?). But I might be mistaken.
<triallax>
i'm converting svg to png, i don't see why it would have trouble with that
<sharkdp>
it looks fine, actually
<sharkdp>
didn't know imagemagick could handle svg
<triallax>
yeah, it's pretty neat
<sharkdp>
Just to be sure: you're creating exports of numbat-wasm/www/icon.svg, right?
<triallax>
correct
<triallax>
which i copied to assets/numbat.svg as well
<sharkdp>
ok. That also has a white background set.
<sharkdp>
can you replace the png versions in numbat-wasm/www as well? I think they should come with a white background, too
<triallax>
sure, but let me try to understand what you want me to do
<triallax>
you want me to add a white background to the PNG files?
<triallax>
and what about the svg file, do i keep it with the transparent background?
<sharkdp>
sorry... yes. I think the icon files should come with a white background instead of a transparent one. 'convert' seems to do that anyway.
<sharkdp>
I guess there's no need to change the SVG files
<triallax>
then it's a problem of consistency i'm afraid
<triallax>
if we're going to encourage packagers to install both the SVG and PNG files, i'd expect them to have the same contents
<triallax>
i'm fine with only having png files for what it's worth
<sharkdp>
ok. that viewport property of svgs does not seem to be implemented everywhere. the recommended solution seems to be to add a 100% width/height rectangle in the background. I can do that if you want.
<triallax>
that sounds good to me
<sharkdp>
Done. Updated your PR
<triallax>
thanks, i'll push my png additions in a bit, busy with something else at the moment
<triallax>
also i should probably test this before merging
<triallax>
should i go into detail regarding where to install the icon files?
<triallax>
i'm inclined to think that this is the responsibility of distro packagers and we shouldn't go overtly into detail
<sharkdp>
it should be done properly at some point, from scratch. Or maybe someone will redesign it completely. But I think that version is better than the icon we had before
<triallax>
the outline is a little jagged yeah, but no big deal
<triallax>
can i squash the commits into something more sensible
<sharkdp>
of course
<achin>
sharkdp: the TZ conversion stuff seems fine to me, the only thing i think i'd like to see right now is a default "let UTC = tz("UTC")" alias.
<achin>
the extra 4 characters do feel a little annoying, but like 98% of all my timezone conversions involve either "local" or "UTC", and so having those being easier (now with 2 less characters!) still feels very nice to type
<triallax>
we can have this in the upcoming hotfix
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
<achin>
a possible counter-argument: users can configure their own favorite timezones in their config file, but i think UTC is special enough to warrent being added to the default
<triallax>
running the suggested command just tells me that 0.7.0 is "required by package `clap_builder v4.5.0`
<achin>
clap_lex is probably requried by clap, so you'll have to downgrade clap as well
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
<sharkdp>
triallax: We have a minimum required Rust version configured in the various Cargo.toml files, and it's currently set to 1.70
<sharkdp>
I'm okay with bumping it to 1.72
<triallax>
the pr is not urgent, we can delay it for after the release
<sharkdp>
Minor point regarding #340: can we move all of those png files and the desktop file into a assets/ subfolder inside the archives? This would also make the Packaging guidelines correct in both cases.
<triallax>
what do you mean, "correct in both cases"?
<sharkdp>
whether you start from the source tree or from the release artifacts
<triallax>
ah
<sharkdp>
because the guidelines ask package maintainers to use the files in assets/
<triallax>
right yeah, that's fine with me
<triallax>
done, let's see if it works
<sharkdp>
Thank you
<sharkdp>
Re "approxidate": should we add "today", "yesterday" and "tomorrow"?
<triallax>
would today be at midnight?
<triallax>
(question also goes for all of these actually)
<sharkdp>
I would research what other tools do, but I think midnight is more useful than noon
<achin>
i don't know how to do this, but it would be nice to have some real-world examples where people use "today" or "yesterday"
<sharkdp>
yesterday and tomorrow are more for fun, but I think 'today' is useful in combination with a 'constructor' like date("2024-04-13")
<sharkdp>
when I just want to ignore times
<achin>
i think if you use something like "today", you probably don't care too much about the arbitrary time used (is it midnight, is it noon, is it my current hour). maybe you want to calculate the number of days between January 1, 1673 and now, and being off by one day does't matter
<achin>
but if i don't care about the exact hour during the day, then using something like now() is no worse than today(), precisely because i don't care about the exact hour
<sharkdp>
it probably doesn't, but it's still nice to get an integer result
<achin>
yes, that's probably true
<sharkdp>
the other argument would be discoverability
<triallax>
adding it would probably be trivial, so i think it's fine
<achin>
btw, chrono has a dedicated type (`NaiveDate`) for this, so if we think that calculations on a date without time, then we should look at using this type
<triallax>
or rather, if you can construct a date from year-month-day, then all you need to do is subtract 1 from day (ignoring any underflows for now)
<triallax>
achin: ah, missed your message, that might be helpful
<sharkdp>
but you need to have the full timezone+DST information to do that, right? or how do you "subtract 1 day" from March 1st?
<sharkdp>
chrono can do it, of course.
<triallax>
exactly, i was hoping chrono would handle it
<sharkdp>
and I was hoping I could implement those functions in Numbat, without new foreign functions :-)
<sharkdp>
or maybe by adding a generally useful additional function
<triallax>
hmm, as it currently stands i don't know if it's possible cleanly
<sharkdp>
I think I'll add today, and forget about yesterday/tomorrow
<triallax>
datetime("2024-01-01") doesn't work, which is kinda sad
<triallax>
i'll open a tracking issue on numbat as well for reference
<sharkdp>
Looks like https://github.com/kennytm/tzfile already implements everything as required. We could use that on unix. And use chrono_tz on other platforms.