Skip to content
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

Allow loading SVG icons from the filesystem #85

Open
MattSturgeon opened this issue Mar 26, 2024 · 3 comments
Open

Allow loading SVG icons from the filesystem #85

MattSturgeon opened this issue Mar 26, 2024 · 3 comments

Comments

@MattSturgeon
Copy link

In addition to glyph_urls remote sources and glyphs embedded SVGs, it'd be useful to be able to load SVGs from the local filesystem.

While you could probably pass file:// URLs to glyph_urls (untested), this would only support absolute paths and would still be cached in the same way as remote SVG files.

Motivation

This would be useful to enable users to define a config that has no online dependencies (at runtime), allowing tools like nix to run keymap-drawer during a "pure" build step.

Currently this is only possible if all icons are defined in the yaml config via glyphs.

Implementation

Perhaps allow glyph_urls to also accept path values? Alternatively introduce a new glyph_paths or glyph_dirs to avoid confusion.

It may also be useful to load specific files. One approach might be to allow glyphs to also support path values. Again, this could be a new option (glyph_files?) if preferred.

Relative paths should be resolved relative to the config file, not the current working directory.

SVGs loaded from the local filesystem shouldn't be cached, regardless of use_local_cache.

@caksoylar
Copy link
Owner

That's a good option to have in general, I agree. I think I prefer the glyph_dirs approach, where you could clone a local copy of e.g. MDI into a folder and simply pass that folder in config.

Relative paths should be resolved relative to the config file, not the current working directory.

I think this makes a lot of sense, but that is currently the most difficult part to implement. Need to add an optional and hidden file source attribute to config.py, and add a getter for some properties that would take it into account.

@MattSturgeon
Copy link
Author

MattSturgeon commented Mar 27, 2024

That's a good option to have in general, I agree.

I'm glad we agree 😀

I scaled back my nix implementation to basically be a glorified shell script, so I no longer need this or #84 to have a working solution.

It'd be nice to be able to build the keyboard renders as a package, but a script in the devshell works fine for now.

So don't go out of your way to solve these just for me, unless you actually think they're worth doing in their own right.

@caksoylar
Copy link
Owner

I think they are worth solving in their own right, but in the absence of an outside push (and the difficulty with relative paths) it might linger in the backlog for a bit 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants