Adopt Feather/Lucide icons

[Jermolene]

Feathericons are an open source library of very nicely drawn SVG icons published under the MIT license. They have the interesting property that they are designed by used at varying line widths. I think this is helpful for accommodating personal taste and accessibility needs.

I propose that TiddlyWiki 5 adopt the Feathericons for the core, replacing the current icons. Where necessary we might need to create additional icons in the Feathericons style, which we will offer to upstream.

https://feathericons.com/%0A

[pmario]

I did have a fast look. It seems not all icon elements are paths. So they will not work with our current hover CSS states, without adjustments. So we'll basically need to create them ourself using that style as a template.

[Jermolene]

Thanks @pmario do give a link to anything problematic if you can.

[mateuszwilczek]

I think a refreshment of TW icons is a very good idea. While each fits its own purpose very well in TW, there are some inconsistencies between them. I was considering proposing some changes to amend these, but moving to a new base might be worth the additional efforts.

I happen to have briefly explored the idea of creating custom icon sets for TW recently. I didn't have time to really do anything useful, but hopefully my observations will offer some additional insight. I will be referring to two large open source icon collections from "big tech" that I looked into, that is Google Material Symbols and IBM UI Icons. There are certainly many other open source sets worthy of consideration, before making the decision to move.

Lucide instead? The Feather set seems to have no active development since some time. I have found some comments that it is considered abandoned. There is its fork, Lucide, on a similar license, with > 1200 icons (Feather has < 300), and it seems to be under active development.

SVG code consistency. This is a huge advantage of Feather/Lucide. As far as I have checked, all icons consist only of strokes, with stroke-width, stroke-linecap, and stroke-linejoin defined in the opening svg tag. This should allow to programmatically "tiddlify" them, and even offer sharp line ends as an option. The same cannot be said about IBM icons - their SVG code is all over the place, using different names and svg elements for identical things. Material Symbols are at least consistent in the code structure, it would be possible to programmatically tiddlify them, but they are offered only as expanded paths, not strokes, even though they mostly consist of lines and are available in many line width options. So each "weight" or "stroke width" option is actually a separate path.

Well, as @pmario mentioned above while I was writing this, this design of Feather/Lucide might not be so good after all. Is rearranging TW to work with stroke-only icons as well as path-only a reasonable thing?

Stroke-only design. In my opinion some icons simply look better when using filled shapes as well, not only strokes (e.g. image with mountains and sun, hexagons with Motovun/puzzle/tools inside, to name a few). The caveats are: I don't know if icons with filled shapes could be as easily adaptable as the stroke-only ones, it would be more difficult to keep them consistent, and merging with upstream would probably not be accepted.

Summing up: I think refreshing TW icons and making them more consistent is a good objective. Lucide offers a wide choice with a good code quality (allowing for easy user customization). There is the issue of support for stroke-only icons in TW, and design issue of sticking to stroke-only icons. These issues and other available open source icon sets should be explored.

[pmario]

Our concept is different. Eg: alert-triangle looks like this. Feathericons uses stroke-width parameter to define the stroke width, which seems to be one reason, why you want to switch.

TW icons do not have a stroke-width atm.

The fill parameter defines the icon colour. The feathericons use it differently

fill and stroke redefined. We would need to completely change our CSS rules, which will cause problems with 3rd party plugins.

[pmario]

It seems, that several sets contained in https://morosanuae.github.io/tw-icons/ do meet the TW affordances and can be directly used.

The only difference is, that the will need the new <<size>> parameter. They use the hardcoded width and size values at the moment.

[pmario]

There is its fork, Lucide, on a similar license, with > 1200 icons

I do like this project. They look good. If we could find a way to "batch convert" them into a format, that is compatible with ours that would be nice.

[pmario]

There seems to be a possibility to use InkScape from the CLI

See: https://github.com/leifgehrmann/svg-stroke-to-path/tree/master
and: https://dev.to/saulodias/convert-svgs-from-stroke-to-path-420j

[mateuszwilczek]

So using Lucide as-is (in the stroke-only form, with ability to change stroke-width on the go) requires a lot of changes in the core and introduces incompatibilities.

If Lucide can be dependably converted from strokes to paths, and if we could also automate the process of "tiddlifying" it (parametrizing size, removing eventual unnecessary metadata, changing to usable TID or JSON format, packing into a plugin), then we could easily offer the icons at a couple of different preset stroke widths as core plugins. Not as adaptable on the go as the stroke-only icons, but also within reach without breaking anything.

But the question is, if it is worth going that far at all for the stroke width variability. If we are to convert Lucide to paths, we may just as well use another icon set, that is already available in path form. The Material Symbols are already available at different stroke widths/ weights, maybe there are other interesting sets like that?

[pmario]

The Material Symbols are already available at different stroke widths/ weights, maybe there are other interesting sets like that?

I did have a look at them from https://morosanuae.github.io/tw-icons/ -- IMO the only one, where the whole set looks OK and has paths, is: Zwicon (565 icons). The last one -- But -- It needs to be optimized in size. The icon set has way more path elements than needed for small sizes we use them. If used as they are, they will need 960 kByte. SVGOMG can probably strip it down to about 30% or more of that size. I only tested it with 4 random complex icons.

Since v5.3.0 SVGs are already backwards incompatible for 3rd party plugins, IMO there would be a chance to change the way core icons work.

In my earlier comments I did not take parametrized transclusions into account, which may make it possible to improve backwards compatibility. Even with stroke-like SVGs

---

I personally do have a Font Awesome 5 Pro license, which is sufficient for my needs. They have 1852 path icons in 4 versions: Solid, Regular, Light and Duotone. -- It would be sad if I'd need to throw them into the bin.

Conclusion

Whatever we decide, we will never be able to use an existing icon set out of the box, because of the flexibility we want to have. 3rd party icons sets will never allow us to use TW macro calls to define width and height=<<size>>

Even if we introduce a "hard dependency" and contribute to that icon set upstream, we will probably need a "build step".

So using the same mechanism https://morosanuae.github.io/tw-icons/ already provides with an official TW icon set seems to be manageable.

• There could be some predefined sets like: Solid, Regular and Light that contain the TW core icons
• With the rest of the icons, users will be able to download user defined sets
• If the configurations would be stored in browser local storage it would also be easy to extend existing sets

Just a thought.

[Jermolene]

Thanks @pmario @mateuszwilczek for the interesting points.

I wasn't aware of Lucide, which does seem a much better candidate.

I agree that the backwards compatibility implications of switching from fills to strokes are tiresome.

I wonder if we can stick with the fill approach, but parameterise the designs to give even more axes of variability than just the stroke width. We'd add a "stroke-width" parameter to the existing TW core icons that would do the maths to vary the stroke width. We might also add a "colour" parameter for easily overriding the colour of the icon without having to use CSS.

I also agree that we're likely to need a build process of some kind.

[mateuszwilczek]

We'd add a "stroke-width" parameter to the existing TW core icons that would do the maths to vary the stroke width.

Generating filled paths from strokes at arbitrary widths inside TW would be very convenient, but from what (little) I have read (here or here), outlining strokes is not a trivial operation, it requires some dedicated libraries or programs (the Inkscape CLI mentioned above). As said, I haven't researched it much, but this might be problematic.

If so, we would have to revert to outlining outside of TW and offering separate icon sets outlined at different stroke widths.

[pmario]

[. . .] outlining strokes is not a trivial operation, it requires some dedicated libraries or programs (the Inkscape CLI mentioned above). As said, I haven't researched it much, but this might be problematic.

Yea I did find similar posts and found the links to the InkScape CLI, which would probably provide us with parts of the "build steps" needed.

• We would first need to set stroke-width to 1
• Create / download the SVGs with that setting
• Convert them to paths
• Add our TW specific classes
• Add our width and height settings
• Add our parameters
• Optimize file size
• Start from the beginning with stroke-width 2 and 3

We already have a step, that optimizes the size of SVGs. I do not know where it is called but probably somewhere in the build steps

We would need run some test, if that workflow would create 3 reasonable icon sets.

[Jermolene]

Generating filled paths from strokes at arbitrary widths inside TW would be very convenient, but from what (little) I have read (here or here), outlining strokes is not a trivial operation, it requires some dedicated libraries or programs (the Inkscape CLI mentioned above). As said, I haven't researched it much, but this might be problematic.

I agree. This is highly speculative but I wasn't thinking that we'd generate the filled SVGs from the paths, but rather than we'd parameterise our filled-style SVGs. We'd make the images out of transformed rectangles for the lines and circles for the line joins and caps.

[mateuszwilczek]

We'd make the images out of transformed rectangles for the lines and circles for the line joins and caps.

This seems like a lot of manual work and there is the issue of more complex shapes not composable using only straight lines and circles.

What we would ideally want sounds a lot like the variable fonts, that is fluid adjustment of the "weight" of complex filled paths. But I have no idea how it's done internally in VFs (interpolation between edge cases would be the simplest, but I have a feeling it is more complex), or whether this analogy helps in anything at all.

In any case, the only icon set that I know with similar properties are the Material Symbols mentioned above. They are distributed as static paths or variable font in 7 weights × 3 grades (sub-weights) = 21 actual weights. It would be interesting to know what are the internals of generating all those variants. I wonder if the webfont does anything more clever than simply storing all those variants as static paths. It is intended to be used over the web and weights 10 MB, so maybe it is just a store of static paths. If so, then this ends up being not a much different workflow than the one described by Mario.

[Jermolene]

That's true @mateuszwilczek, we are in danger of reinventing variable fonts...

[pmario]

I wonder if the webfont does anything more clever than simply storing all those variants as static paths. It is intended to be used over the web and weights 10 MB, so maybe it is just a store of static paths.

Fonts are big, if they contain character definitions for many different languages. Variable fonts work based on rules, that are defined for every single character. Good looking fonts are a good amount of work to define, depending on the number of dynamic parameters and the number of characters off course.

The WOFF2 file size of variable fonts can range from ~30kB for a fixed type up to ~300kB if all parameters are adjustable for a "basic Latin character set"

Ordinary OTF fonts are big because they do contain "static paths" and many languages. Usually they are split into different files to make them manageable.

If so, then this ends up being not a much different workflow than the one described by Mario.

My workflow description was just an idea, if we stay with paths. Converting stroke based icons into path will be complex and a lot of experiments needed. InkScape's CLI function will be needed.

I think it's impossible to dynamically change the "line width" of our path based icons, because the path defines the outline. The perceived "lines" in reality are the filled areas. Our icons do not have a "stroke" definition at all, because it would make the outline visible. see screenshot:

Changing the stroke-width would only make the outline stroke thicker. It will not change the path.

---

So we do have to decide if we want to stay "path based" or if we want to switch to "stroke based" icons, to use the Lucide icon set.

We still would have to add new CSS rules based on the classes already defined with the Lucide icons.

If we want to have dynamic parameters on a per icon basis, we will need a build step, that inserts TW macro calls into the SVG code. So we can use parametrised transclusions to call them. see screenshot above.

The js-code to insert custom parameters into SVGs is not overly complicated, since native DOM manipulation functions can be used. The most time consuming part will be testing and see if all icons still work afterwards. I did create a custom SVGs for TWclassic. (some time ago :)

I think our fake-DOM has enough functionality to enable the command line to insert the needed parameters but I'm not sure about that.

[pmario]

It seems the Lucide project do have a lot of scripts, which allow SVG manipulation already. Not sure about the possibilities yet: https://github.com/lucide-icons/lucide/tree/main/scripts

[Alzacon]

If we want to have dynamic parameters on a per icon basis, we will need a build step, that inserts TW macro calls into the SVG code. So we can use parametrised transclusions to call them. see screenshot above.

About parametrised transclusions in presentation attributes there are some points to consider:

• Their values, in the cascade, are overwritten by all other styles except the “User Agent Styles”. (See the example for tests)
• How the transclusion works when the user set parameters for the 1st and 4th of these attributes without use the transclude widget. Maybe there is possible atm but I don't know the use of parameters in the shortcut for parametrized transclusion: {{tiddler |param1|param4}}?.

Maybe the parametrized transclusion can be used to add a class or set the inline styles. And it could help to remove some attritubes of svg tag and they can use to normalize the styles with CSS.

For your example:

<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="yellow" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-x-circle">

It could be changed to:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" class="lucide lucide-x-circle">

(without the inline styles or new added class)

---

example for tests

<p class="dummy">It is a dummy text with a svg

<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="yellow" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-x-circle"><circle cx="12" cy="12" r="10"/><path d="m15 9-6 6"/><path d="m9 9 6 6"/></svg>

</p>

<style>
.dummy {/**
color: green;/**/
}

.dummy svg{
width: 24px;
height: 24px;

fill: none;
stroke: currentColor;
stroke-width: 2;
stroke-linecap: round;
stroke-linejoin: round;
}

svg.lucide-x-circle{/**
stroke: purple;/**/
fill: orange;
}
</style>

[oeyoews]

The feather icon repository is almost no longer maintained, lucide is a good choice

[mateuszwilczek]

I have made a simple wiki to compare the current core icons with the sets we have been discussing: https://new-icons.tiddlyhost.com/

Adjustments can be made to the Lucide and Material icons, see details here.

I have chosen the best matching existing icons from Lucide and Material sets, commenting where we would surely or probably need custom icons. For each set there is only a couple of such. Most of the core icons have a good match among the existing Lucide and Material icons.

Purely visually, I find Material slightly better overall. In certain cases, e.g. globe, line-width, picture, it looks better IMO, because it is not limited to lines only and can have some filled spaces. But in some other examples like copy-clipboard or subscript/superscript I think Lucide comes on top by not having too many thin details.

In practical terms, I guess working with Lucide will be more inviting copyright-wise than depending on Google's work. It should also be much easier to design custom icons in a coherent style for Lucide than for Material.

I have matched only a couple of Zwicons, as I think they are too thin and would not work for us at all.

[mateuszwilczek]

Let's revive the discussion.

I have made some basic checks, and the Inkscape CLI seems promising as an intermediate step of outlining the paths of Lucide icons.

For example:

inkscape --actions="select-all;object-set-attribute:stroke-width,1;object-stroke-to-path;object-set-attribute:stroke,none" --export-filename="output.svg" input.svg

this command will convert input.svg to output.svg while changing the stroke width from default 2 to 1 and then outlining the strokes.

So this would certainly be one way to go if we find no other easier way. Of course we would need the further steps to clean up and optimize the SVG, as described by @pmario.

I have also noticed a couple of mentions of "outline" and "lucide font" in the Lucide repo: https://github.com/search?q=repo%3Alucide-icons%2Flucide%20outline&type=code

I don't know much about JS and can't make much out of it, but maybe there is something useful to us already.

[pmario]

I have also noticed a couple of mentions of "outline" and "lucide font" in the Lucide repo: https://github.com/search?q=repo%3Alucide-icons%2Flucide%20outline&type=code

That's good. There is a ouitline build command. It seems I did just build an outlined version of the whole set. A bit more experimenting needed.

I actually do not know, how they do that, but it seems to work.

[pmario]

It turns out, that converting SVG into icon-fonts needs them to be outline based. So the lucide-project use a project https://github.com/oslllo/svg-fixer which seems to does that job well.

It uses "precision" 3, which makes path based icons larger as they need to be. For our usecase precision 2 would be enough. Which probably makes the them ~30% smaller.

There are also some parameters, that we do not really need. Which should give us an other 5% or so.

[pmario]

I did a bit of tinkering and just batch processed 1447 Lucide svgs into TW *svg.tid files ready to import into TW ;)

That's cool, but there are some problems too. Some of the core images have hardcoded classes. One of them is unique eg: tc-image-palette as shown in the screenshot. IMO those unique classes are good for individual colouring.

The newly imported Lucide icons do not have those classes. IMO it's easy to assign non-uniqe classes like tc-image-button, because all of them have them. In the core luckily use tc-image-button to assign width and height.

But the unique classes would need some "special meta-data mapping", since there are 1447 Lucide icons and only about 130 core SVGs.

@Jermolene Mapping special meta data is doable but it will create some extra maintenance burden on our side. We would need to agree on a "core mapping set" which would be OK

But there is a very high chance that some users may want to use a different mapping. So we probably will need a completely new edition for icon-mapping :/

What do you think

[pmario]

Looks better now :)

[Jermolene]

Hi @pmario this work is very promising. Alternate icon sets work well as plugins, and I would think in the first instance the core would offer the replacement icons as a plugin. Once we have a viable alternate set that meets the criteria for the core then we could consider changing the icons shipped in the core.

[pmario]

I did have a closer look at the whole icon set yesterday evening and I did find about 80% to 90% of the icons we need. But there are some icons, which are definitely missing. Like "close others", "fold-all", "fold-others", "new-here", "new-journal-here" and so on.

The Lucide project has some well defined Icon Guidelines , which we can adopt for the Lucide Icon Set

[mateuszwilczek]

Mapping special meta data is doable but it will create some extra maintenance burden on our side

I think we would need a "dictionary" to translate from Lucide to TW icon names anyway. This dictionary could also contain the custom unique classes.

I did find about 80% to 90% of the icons we need

I agree, there is a close match for most of TW icons, as in the demo I've set up: https://new-icons.tiddlyhost.com/

I won't be able to help much with setting up of the whole automated process, but I'd be glad to help with things like creating the map/dictionary of icon names/classes or designing the lacking icons.

One idea, maybe it has been meant all the time, but I want to clarify. I hope we can outline, optimize, and "tiddlify" (parametrize, assign common classes) all Lucide icons and store that somewhere, and then have only the selected core icons go further through assigning unique classes and renaming to TW names. That way we would have a library of icons in a format ready to use in TW, from which users could just copy-paste the code or upload *.tid to TW if they need some additional icons.

[pmario]

I think we would need a "dictionary" to translate from Lucide to TW icon names anyway. This dictionary could also contain the custom unique classes.

You are right. I did think about that too. As Jeremy suggested, we will need to create a plugin for the new icons. The whole new icon-set will be about 2Mbyte, which is a bit heavy if 90% of the icons are not used.

I won't be able to help much with setting up of the whole automated process, but I'd be glad to help with things like creating the map/dictionary of icon names/classes or designing the lacking icons.

I do have the automated process already. I'll have to create the dictionary myself, since I do not know atm, how it will look like.

One idea, maybe it has been meant all the time, but I want to clarify. I hope we can outline, optimize, and "tiddlify" (parametrize, assign common classes) all Lucide icons and store that somewhere,

It's meant to be that way. The file-name / title mapping at the moment is like this eg:

• a-arrow-down.svg -> a-arrow-down.svg.tid -> title: $:/lucide/images/a-arrow-down -- for the library in general
• palette.svg -> palette.svg.tid -> title: $:/core/images/palette -- for the core icons in general

The .tid file header will look like this

title: $:/core/images/palette
tags: $:/tags/Image/Lucide 

\parameters (size:"22pt")
<svg xmlns="http://www.w3.org/2000/svg" width=<<size>> height=<<size>> class="tc-image-button" viewBox="0 0 24 24" fill="currentColor" stroke="none" stroke-width="0"> ...

... and then have only the selected core icons go further through assigning unique classes and renaming to TW names. That way we would have a library of icons in a format ready to use in TW, from which users could just copy-paste the code or upload *.tid to TW if they need some additional icons.

That's the way I thought that too. The plugin contains the core/images. A second plugin, which contains all icons can be used to create user defined mappings. -- For the beginning users will need to do that manually.

All of this works already. The automatic core plugin creation does not exist at the moment. But I'm no it.

[tchuffart-fr]

I'm happy to see this subject coming back to life. For your information, I've designed some specific TW icons to complete the Lucide package.
You can explore them on this wiki

I'm not expert enough to include those SVG's to the Lucide Package, please feel free to add thoses icons to the Lucide project for me.

[Jermolene]

Thanks @tchuffart-fr those icons are really expertly done, and work really well.

Perhaps we're closer to being able to have a new core icon set for 2024 than I thought.

[tchuffart-fr]

I've just corrected slightly the list of icons, because I've also modified the $:/core/images/save-button-dynamic to match the set.
You can see and experience it on this wiki.

[pmario]

I've just corrected slightly the list of icons, because I've also modified the $:/core/images/save-button-dynamic to match the set.

That's very nice, but there are some problems with the viewbox <svg width="1em" height="1em" viewBox="0 0 5 5">

Do you know about the icon-guidlines? .. It seems the "home" icon is too big and the right-sidebar "+" icon is a bit too small.

This will definitely save us much work - Thanks a lot.

[pmario]

I did create a discussion at Lucide: lucide-icons/lucide#2005

[pmario]

@tchuffart-fr ... Do you have "stroke-based" SVGs before they have been changed to outlines?

[pmario]

I did find a way to make our path based icons thinner with 2 new parameters

default

Using Outline Stroke - Background Colour

So if the stroke is in background colour it will make the icon-fill area smaller. Probably as small as we want.

@mateuszwilczek ... So it should be possible to have 2 more parameters and we are able to dynamically make the icons "thinner" or "thicker"

[mateuszwilczek]

So if the stroke is in background colour it will make the icon-fill area smaller. Probably as small as we want.

If we can reliably make the stroke a given color (background), couldn't we just use the stroke icons and have the stroke take the foreground/fill color?

Or did you mean that it can work but only if manually adjusting for the bg color?

And if I'm missing something and this won't work -- could we make the thing you just did but in reverse? That is, outline the icons at the thinnest setting, and then make them appear thicker by applying foreground/fill colored stroke? This would cover the case of displaying icons over a non-homogeneous background like image.

[pmario]

Or did you mean that it can work but only if manually adjusting for the bg color?

No we should be able to dynamically assign the right background colour.

couldn't we just use the stroke icons and have the stroke take the foreground/fill color?

No -- They are not backwards compatible.

---

And if I'm missing something and this won't work -- could we make the thing you just did but in reverse? That is, outline the icons at the thinnest setting, and then make them appear thicker by applying foreground/fill colored stroke? This would cover the case of displaying icons over a non-homogeneous background like image.

IMO That would be like reinventing the wheel. If we do that, we can use the Lucide stroke-based icons (which are much smaller in file size) and redesign our UI. It will probably cause less trouble. -- But would be not backwards compatible

[mateuszwilczek]

Ok, then your idea seems very good! I think in testing we should pay attention if there any artifacts in displaying those strokes on different sizes and on different platforms, but it looks good on your screenshots.

[tchuffart-fr]

@tchuffart-fr ... Do you have "stroke-based" SVGs before they have been changed to outlines?

I did have them because I created them, but I can only find the inscape file with the outline ones. I could make them again.
But how should they be transmitted to you ?

• the inkscape original file (one file per icon or all icons side by side)
• a svg file just exported from inkscape (with no TW parameters) and optimized by SVGOMG
• a .tid file wth TW parameters

I looked at the Lucid site but it seemed a bit confuse to me how to send the icons there (I'm not a github master, just contributing as much as I can).

[mateuszwilczek]

It's up to Mario of course, but I'd bet it's best to share original Inkscape files (with stroke icons) between us as long as their design is being discussed and they are being adjusted to Lucide guidelines.

Once they are established, we can export them from Inkscape and optimize through SVGOMG - at this point we should be able to:

• commit to Lucide repo
• if it takes long for them to be accepted, maybe we can "side load" them and process as if they were in Lucide repo to make them ready for TW

I have some minor suggestions on the custom icons, to make them more consistent with the rest of Lucide set - e.g. use only 45° and 90° angles in the chevrons/ fold icons. We will also have to follow Lucide naming guidelines if we want our custom icons to be accepted.

I should be able to draw my ideas during the next couple of days and share.

Also, I think there are some custom icons as described in Mario's post here lucide-icons/lucide#2005 (comment) which do not necessarily need being custom designed, there are viable alternatives in Lucide, e.g. timer off, open in new window.

[pmario]

I did have them because I created them, but I can only find the inscape file with the outline ones. I could make them again.
But how should they be transmitted to you ?

I did recreate all of them already, using the Lucide guidelines. Thx

[pmario]

It's up to Mario of course, but I'd bet it's best to share original Inkscape files (with stroke icons) between us as long as their design is being discussed and they are being adjusted to Lucide guidelines.

I did create them using the guidelines as good as I can understand them. Here is a screenshot of unoptimized svgs

Once they are established, we can export them from Inkscape and optimize through SVGOMG

Converting them to outlines and optimizing can be in our workflow. I do already use the "svgo" package to convert Lucide "outline" folder to TW .tid files, which contain the header, the new tags and the \parameters

Converting the newly created stroke based icons to the Lucide SVG standard -> converting them to outlines -> .tid files is still a TODO

I do have 95% of the "mapping" lucide file-names -> tiddler-names in place already.

[pmario]

There are definitely some icons which probably can never be Lucid standard. Eg the line-width IMO the Lucide concept cannot handle that type of icons.

The Lucide naming convention is also a bit weird. It's very likely, that I did name some of them in the wrong way. There has not been any feedback from upstream. But I think some of the icons will be a good fit for them too.

I did also create an Inscape template, with a backdrop of "circle" and "square" to have a reference for the "optical volume" they mention in their guidelines. The Inkscape "originals" will be part of the repo, that will go to GitHub.

Icons containing "chevrons" IMO currently are "low volume" in Lucide

Our storyview-pop will be one with a "high volume" which will be hard to make it smaller. So they may stay custom forever

---

Problem with "high volume" icons -- 3px stroke setting

[mateuszwilczek]

line-width IMO the Lucide concept cannot handle that type of icons

For this one I thought of, from top to bottom: line, narrow horizontal rectangle, wider horizontal rectangle. But I fear this might not convey the meaning good enough. Alternative would be to maybe use the pen-tool icon:

There are definitely some icons which probably can never be Lucid standard.
This goes for the plugin icons, if we want them to be filled-in hexagons. Also the trick for making wider/thinner would not work for them.
Maybe we could try to simplify/change the design of the symbols inside the hexagon, so that we could use Lucide-conform stroke only design, but that would be tricky.

The Lucide naming convention is also a bit weird.
It seems weird for some of them, but I guess it's supposed to make them more universal. Our "unsaved changes" or "excise" icons could just as well be understood/used as "CD"/"circled dot operator" or "indent" (if flipped 90°)/"extrude".

[pmario]

Our "unsaved changes" or "excise" icons could just as well be understood/used as "CD"/"circled dot operator" or "indent" (if flipped 90°)/"extrude".

Yea, especially "excise" may probably rotated by 90° clockwise.

I also like the new "advaced search" quite a bit. But I did not test it within TW. I did create them yesterday evening-night :) -- Since the converter code is not in place I did not test them with TW yet.

[mateuszwilczek]

I did create them using the guidelines as good as I can understand them.

Looks good! I have a couple of minor suggestions again, but it will probably be better to draw what I mean rather than write. I'll try to do it in the evening.

[pmario]

Here is the Inkscape template and the stop-watch that I use atm.

Lucide-Template.zip

A link to Lucde search by category: https://lucide.dev/icons/categories
Lint to style guides: https://lucide.dev/guide/design/icon-design-guide

[tchuffart-fr]

Nice work @pmario.
Concerning the storyview icons, I think they are a bit confusing.

In my version I tried to keep it simple enough to convey an idea of the result and differenciate them enough one from the other.

In your design I think there is too much horizontal lines. But I understand your purpose to mimic the aspect of a list of diffrent tiddlers stacked on top of each other.

At small size, the difference should be immediatly seen.
And the overall design of the Lucid Icons is light and simple.

In anyway, it is necessary to try them in situ in a wiki. Is it possible to create that for us to experiment those candidate icons and eventually discuss for adaptations. Sometimes it is just a question of a pixel or a gap too wide or too thin to obtain the perfect design.

[Jermolene]

Hi @pmario I am not sure I am following this discussion properly:

• Have you made a set of TW-specific icons in the Lucide style?
• Where can I see these icons?
• Has @tchuffart-fr created a different set of TW-specific icons? (I have already located these)
• If so, I would like to see them side-by-side for comparison

[pmario]

Have you made a set of TW-specific icons in the Lucide style?

Yes. I did an explorer preview screenshot at: #7652 (comment) These are most, which do not have existing Lucide icons. I surely missed some. Especially there are some core plugins which also implement icons. I did not do any of them yet.

Has @tchuffart-fr created a different set of TW-specific icons? (I have already located these)

Yes -- But they are outline style using paths and they use the wrong viewBox setting. I did use @tchuffart-fr icons as a guide and I did some of my own experiments.

To be able to use the Lucide automated "build" system, I did use their style-guide for the new set. Nothing is optimized yet. Once we are sure, we like them, we may be able to create PRs upstream. At least for some of our icons.

Lucide icons are very small in size.
The whole "outlined" icon-set (~1450 icons) with paths will need 1.8Mbyte if imported into an TW edition.

If so, I would like to see them side-by-side for comparison

Soon, once I do have the automated build system in place. I should be able to create a TW plugin. The plugin should be a drop in replacement. The plugin will be created using a single build command.

Lucide stroke icons are relatively simple to modify. There is an automated build-system, for cleaning, optimizing and pretty printing the SVGs. The build command for all icons, sends them to an "outline" directory.

My new scripts can use the "outline" directory. It runs a second conversion step, which reduces the floatPrecision to 2, to reduce the icon size. It then converts them into .tid files.

With the new project I did create, we should be able to build Lucide style icons, convert them to SVG outlines, clean, optimize them and then convert them to tiddlers. These tiddlers will use \parameters and the <<size>> variables. So we can directly import all our own and the 1450 Lucide icons into TW if needed.

At the moment I'm creating the the automated plugin creation scripts. I think the whole thing should be presentable next week.

[Jermolene]

Thank you @pmario that's very helpful, and very encouraging.

[mateuszwilczek]

My designs for some icons: https://lucide-icons-wilk.tiddlyhost.com/

My suggestions, referring to @pmario's designs:

• a-b, a-b-c-d - I find the ABCD a bit too cluttered, we could use code and square-code instead
• App-window-arrow-up-right - why not simply use external-link or square-arrow-out-up-right
• circle-circle - we could use the existing circle-dot or rotate circle-stop 45° to get a design that was alternate thing to the circle dot when it was introduced; for close others/focus we could use focus
• image-arrow-up-right - feels a bit cluttered, maybe use scaling, it is used in context where it is clear that an image is being resized
• search-advanced - see my search-ellipsis
• stop-watch and stop-watch-pause - use timer and timer-off, or timer with pause sign, but without the additional buttons
• storyview:
  • gallery-vertical for classical
  • rectangle-horizontal for zoom
  • see my gallery-vertical-pop for pop
• folding:
  • chevrons-down-up for fold tiddler, chevrons-up-down for unfold tiddler
  • see my chevrons-down-up-double and chevrons-up-down-double for fold/unfold all
  • see my rectangle-horizontal-chevrons-up for fold others (there is also chevrons-down for pair, but won't be used in TW)
• height fixed/auto - see my line-arrow-up-down-line and line-arrow-dashed-up-down-line or move-vertical-dashed and move-vertical
• double brackets and braces - see my double-brackets and double braces

Sorry for the emotionless imperative tone, this is just to keep things brief. I'm open for discussion of course :)
My demo wiki contains Inkscape's SVGs and they're not necessarily pixel-perfectly aligned, so they need checking before eventual further steps if we choose any of them.

[mateuszwilczek]

Some minor changes, all my designs are again here: https://lucide-icons-wilk.tiddlyhost.com/

I think square-chevrons-down-up.svg and square-x-x.svg would play nicely with other folding icons:

• fold/unfold this tiddler icons (chevrons-down-up from Lucid) have two elements
• fold other and close other (my icons as above) have three elements
• fold all and close all (my fold all and Mario's close all) have four elements

I'll draw some other ideas that I have and organize everything in the evening or during the weekend.

[CodaCodr]

These look great.

I noticed that the following pair seem to have their names swapped?

rectangle-horizontal-chevrons-up.svg
rectangle-horizontal-chevrons-down.svg

[tchuffart-fr]

Nice propositions but to decidie we need to compare the different propositions side by side (with the original TW icon as reference)
And it's also important to visualize those icons in context in a wiki or a mockup of it.

[mateuszwilczek]

For easier comparison in https://lucide-icons-wilk.tiddlyhost.com/ I made a table with all core icons, the existing Lucide icons I would choose, and my custom icons:

[mateuszwilczek]

I have added some more custom designs in the meantime, sometimes in a few variants for a given icon, here are all of them:

It is easier to evaluate in the table, comparing to current core icons of course.