-
Notifications
You must be signed in to change notification settings - Fork 27
Maybe use something like https://iconify.design as icon source #8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This is surely something to consider. I don't like the fact that a user has to be online to use the iconify API. The other way to do this would be to download the iconify icons. This would work, but we are already downloading every icon package, and I would prefer that only required icon libraries be downloaded to reduce the crate size because a crate can be a maximum of 10MB in size. This is why I personally prefer the more fine-grain approach. Do you see any advantages to using iconify? |
I got the impression that it's nontrivial amount of work to add a new icon
set to the library in a unified way and most of that work is already done
by projects like Iconify, so I proposed it.
I don't think that online approach will work. For offline, I propose having
each image set in a separate crate. The main crate will conditionally
depend on feature-enabled image sets only. This approach is scalable to any
number of sets. It also means the user won't download image sets that are
feature-disabled.
Another idea to reduce crate size is that image set crate will only contain
a json file and a build script that generates classes from it. The build
script should be a single call to yet another crate so the builder code is
compiled once even when multiple image sets are enabled.
…On Thu, 30 Mar 2023, 19:01 Charles Edward Gagnon, ***@***.***> wrote:
This is surely something to consider.
I don't like the fact that a user has to be online to use the iconify API.
The other way to do this would be to download the iconify icons. This would
work, but we are already downloading every icon package, and I would prefer
that only required icon libraries be downloaded to reduce the crate size
because a crate can be a maximum of 10MB in size.
This is why I personally prefer the more fine-grain approach.
Do you see any advantages to using iconify?
—
Reply to this email directly, view it on GitHub
<#8 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFQQIXWTW424T6MXLIKCL3W6W35LANCNFSM6AAAAAAWNQJLRY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
* Add one codecov * Merge another codecov * Merge another codecov * Merge another codecov * Merge another codecov * Place codecov config under .github * Add (only) ASAN workflow * Add first coverage workflow * Merge another coverage.yml * Merge another coverage.yml * Add first features workflow * Merge another features workflow * Merge another features workflow * Merge another features workflow * Add (only) loom workflow * Add (only) LSAN workflow * Add first minial workflow * Add (only) miri workflow * Add first msrv workflow * Merge another msrv workflow * Merge another msrv workflow * Merge another msrv workflow * Add (only) no-std workflow * Add first os-check workflow * Merge another os-check workflow * Add first style workflow * Merge another style workflow * Merge another style workflow * Add first test workflow * Merge another test workflow * Merge another test workflow * Merge another test workflow * Make everything use checkout@v3 * Standardize on 'main' as branch name * Missed a submodule checkout * Add TODOs from twitter thread * Practice what you preach * mv github .github This should make it possible to have rust-ci-conf as a remote you merge from. * Merge safety workflows * Catch upcoming deprecations * More concise name for scheduled jobs * Allow examples and binaries to require features * Use dependabot, but only for major versions * ignore is a list * Notify if actions themselves are outdated * Bump codecov/codecov-action from 2 to 3 Bumps [codecov/codecov-action](https://github.com/codecov/codecov-action) from 2 to 3. - [Release notes](https://github.com/codecov/codecov-action/releases) - [Changelog](https://github.com/codecov/codecov-action/blob/main/CHANGELOG.md) - [Commits](codecov/codecov-action@v2...v3) --- updated-dependencies: - dependency-name: codecov/codecov-action dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]> * Move to maintained rust installer See actions-rs/toolchain#216 * Fix install message for msrv * Get rid of most actions-rs bits Given that that project is unmaintained. actions-rs/toolchain#216 * Minimal token permissions See tokio-rs/tokio#5072 * Remove -Zmiri-tag-raw-pointers as it's now default * Unbreak cargo hack for non-libraries (#4) * Add action to run doctest. (#3) `cargo test --all-features` does not run doc-tests. For more information see rust-lang/cargo#6669. * chore: automatically cancel superseded Actions runs (#5) * [sanity] More robust injection of opt-level 1 (#9) Fixes #8 * Quote MSRV version to avoid float parsing (#11) Put 1.70 in there (for instance if you want to pin against OnceLock stabilizing) and it will actually test 1.7 as it appears github auto converts this to a float? Putting in quotes seems to do the right thing here * Install Openssl for Windows (#12) * Don't install OpenSSL on Windows by default * Bump actions/checkout from 3 to 4 (#13) Bumps [actions/checkout](https://github.com/actions/checkout) from 3 to 4. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v3...v4) --- updated-dependencies: - dependency-name: actions/checkout dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: Jon Gjengset <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Tudyx <[email protected]> Co-authored-by: Burkhard Mittelbach <[email protected]> Co-authored-by: Simen Bekkhus <[email protected]> Co-authored-by: James Chacon <[email protected]> Co-authored-by: Rod Elias <[email protected]>
Maybe it will be easier to uniformly integrate multiple icon sets by using some icon set aggregator? I know that Iconify has a repository with all the icons as json files: https://github.com/iconify/icon-sets/tree/master/json.
The text was updated successfully, but these errors were encountered: