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.

[mateuszwilczek]

The "filled icons" and the "dynamic icons" can not be done with Lucide.

Dynamic icons are: $:/core/images/network-activity, $:/core/images/save-button-dynamic and $:/plugins/tiddlywiki/tiddlyweb/icon/cloud

Filled icons

• $:/core/images/star-filled perhaps it's best to stick to a filled design for an icon that explicitly has "filled" in its name. Since this is in a plugin stage and we have some flexibility to experiment, perhaps we could add e.g. a $:/core/images/star-outline icon that would use an unchanged star icon from Lucide set? For those who would like to use a consistent style of lucide icons.
• the hexagon-based filled icons require more thought, it's not so easy to redesign them in Lucide style
• $:/core/images/mastodon -- I could draw it in Lucide style and try to contribute to the Lucide repo

Dynamic icons

@pmario what do you mean these can not be done with Lucide? They obviously cannot be taken directly from Lucide repo if we need them to be dynamic in TW. But these three seem to be quite easy to create by combining existing Lucide icons or design in Lucide style. I'm up for that too.

---

So to sum up, I could start working on:

• $:/core/images/mastodon
• $:/core/images/network-activity
• $:/core/images/save-button-dynamic
• $:/plugins/tiddlywiki/tiddlyweb/icon/cloud

in Lucide style, or based on Lucide-conform shapes but made dynamic for TW.
That is, if no one has already made it. @pmario @tchuffart-fr ?

[pmario]

Demo can be found at: https://pmario.github.io/lucide-tiddlywiki-plugin/

[pmario]

$:/core/images/mastodon -- I could draw it in Lucide style and try to contribute to the Lucide repo

I did read somewhere, that they want to get rid of all "brand icons" -- So I'm pretty sure it will be rejected. But that's not a problem. We do have our own "build" system in place now.

repo: https://github.com/pmario/lucide-tiddlywiki-plugin

The origin directory contains our custom icons set.

Which we can try to reduce in the future by contributing them to upstream lucide. -- But that has time.

---

The new-journal button at the moment needs some hand-crafting, since we do want to show the actual day of the month inside the icon. So it has to be done manually at the moment.

[pmario]

So to sum up, I could start working on:

Do not do this. All of them are dynamic buttons, that can not be created with code at the moment.

• $:/core/images/network-activity
  • I did add radio-tower and radio-tower-off ... but the network-activity has to stay as it is atm
• $:/core/images/save-button-dynamic
  • I did add $:/core/images/save-button which is not dynamic. We can use that one from Lucide directly
• $:/plugins/tiddlywiki/tiddlyweb/icon/cloud
  • This one also has to stay. -- I will add a cloud icon with the next push

[pmario]

The system contains a tiddlywiki-mappings.json file, that can be used to configure, which icons we do want to have in the core.

It's very simple now. The config structure looks like this now: I'll comment directly in the JSON code

There are 41 custom icons at the moment.
They are created with InkScape in the "origin" directory.
Then they are converted from "line-icons" to "path-based" icons and they are transformed to .tid files using the "scripts" here. No manual tinkering with \parameters and width=<<size>> wikitext needed anymore.

{
	"$:/core/icon": {               // TW tiddler title
		"lucide": "TODO",       // If there is no icon yet TODO is a placeholder
		"customDir": "custom",  // This is a TW specific icon and comes from the "origin" directory 
		"classes": ["tc-image-$(title)$","tc-image-button"] // TW classes with $(title)$ placeholder
	},
	"$:/core/images/add-comment": {
		"lucide": "message-circle-plus.svg.tid",  // If there is no customDir the icon comes from the Lucide upstream library
		"classes": ["tc-image-$(title)$","tc-image-button"]
	},
	"$:/core/images/advanced-search-button": {
		"lucide": "search-code.svg.tid",
		"classes": ["tc-image-$(title)$","tc-image-button"]
	},
	"$:/core/images/auto-height": {
		"lucide": "lines-arrow-down-center-dashed.svg.tid",
		"customDir": "custom",
		"classes": ["tc-image-$(title)$","tc-image-button"]
	},

So if we do want to add a new icon from Lucide upstream we only need to add a new element to the mapping

	"$:/core/images/new-icon-name-in-tw": {
		"lucide": "<lucide-name-comes-here>.svg.tid",
		"classes": ["tc-image-$(title)$","tc-image-button"]
	},

Then a new build run and a push are needed. -> Done

[pmario]

I do want to build a lucide-all edition, which contains all 1500+ icons converted into TW format. The main problem is size. The full size will be 3.5+ MByte.

That's the disadvantage of path-based icons. They are much bigger than line-based icons.

The advantage is, they can be filled, which is a big problem for line based icons.

• The next step is to build an edition, which contains all the Lucide Icons.

• We are able to use the upstream meta data to create a search function similar to https://lucide.dev/icons/categories?search=calendar

  • At the beginning we will need to use their search function to find the right icons

• Then we can have a look if dynamic icons can be built with an algorithm. -- Not sure if that's worth it.

[mateuszwilczek]

I did read somewhere, that they want to get rid of all "brand icons" -- So I'm pretty sure it will be rejected. But that's not a problem. We do have our own "build" system in place now.

Thanks for the heads up. It shouldn't be a lot of work to create it, I'm okay with it staying only in TW.

Do not do this. All of them are dynamic buttons, that can not be created with code at the moment.

I thought of manually creating tiddlers for the three dynamic icons, using the designs already present in Lucide (maybe except for the cloud with a tick).
These would bypass the whole building process that you set up. Since these are only three icons, for now it is probably easier to make these three manually instead of inventing a smart way to automate it. I would convert from lines to outlines (or use the outlines you have already created, like the antennas) and manually create a tiddler with relevant classes for the dynamic display.

The intended result is that the dynamic buttons, especially the very important save button, would match the design of other icons.

[tchuffart-fr]

Hello. I already made some specific icons in lucide style for TW. But I don't know how to transfer those to lucid database. I can make them accessible as individual SVG files.. they are also visible on my site on tiddlyhost. Envoyé depuis Proton Mail pour Android

…

-------- Message d'origine -------- Le 27/09/2024 11:13, Mateusz Wilczek a écrit :

> The "filled icons" and the "dynamic icons" can not be done with Lucide. > > Dynamic icons are: $:/core/images/network-activity, $:/core/images/save-button-dynamic and $:/plugins/tiddlywiki/tiddlyweb/icon/cloud Filled icons - $:/core/images/star-filled perhaps it's best to stick to a filled design for an icon that explicitly has "filled" in its name. Since this is in a plugin stage and we have some flexibility to experiment, perhaps we could add e.g. a $:/core/images/star-outline icon that would use an unchanged star icon from Lucide set? For those who would like to use a consistent style of lucide icons. - the hexagon-based filled icons require more thought, it's not so easy to redesign them in Lucide style - $:/core/images/mastodon -- I could draw it in Lucide style and try to contribute to the Lucide repo Dynamic icons ***@***.***(https://github.com/pmario) what do you mean these can not be done with Lucide? They obviously cannot be taken directly from Lucide repo if we need them to be dynamic in TW. But these three seem to be quite easy to create by combining existing Lucide icons or design in Lucide style. I'm up for that too. --------------------------------------------------------------- So to sum up, I could start working on: - $:/core/images/mastodon - $:/core/images/network-activity - $:/core/images/save-button-dynamic - $:/plugins/tiddlywiki/tiddlyweb/icon/cloud in Lucide style, or based on Lucide-conform shapes but made dynamic for TW. That is, if no one has already made it. ***@***.***(https://github.com/pmario) ***@***.***(https://github.com/tchuffart-fr) ? — Reply to this email directly, [view it on GitHub](#7652 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/APVDEA3AR5SZGPC2QJFEXB3ZYUOURAVCNFSM6AAAAAA26STW2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZYHAZDGMRVG4). You are receiving this because you were mentioned.Message ID: ***@***.***>

[pmario]

.. they are also visible on my site on tiddlyhost.

Can you link to that site? -- I did take the story-view buttons from your posts. They where better than mine.

[tchuffart-fr]

Here it is... https://feathericonset.tiddlyhost.com/ Envoyé depuis Proton Mail pour Android

…

-------- Message d'origine -------- Le 27/09/2024 15:23, Mario Pietsch a écrit :

> .. they are also visible on my site on tiddlyhost. Can you link to that site? — Reply to this email directly, [view it on GitHub](#7652 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/APVDEA4YK2ZJVIWRU4ND6ADZYVL3LAVCNFSM6AAAAAA26STW2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZZGI3TKOBVGA). You are receiving this because you were mentioned.Message ID: ***@***.***>

[pmario]

• Just updated the demo so new-journal shows day of month again.
• The plugin now has a version number v5.3.5-beta-***

[Leilei332]

IMO we can use some icons in Tabler, which has a similar style to Lucide. So that brand icons like mastodon and discord can be replaced

[kookma]

Sidenote:
I feel the icons are a little thin! On desktop and big screens, they look even thinner.

[pmario]

I feel the icons are a little thin! On desktop and big screens, they look even thinner.

That's the beauty of those icons. They look more elegant.

As I wrote in my comment here in the tread it is possible to add some more paramters.

Even if our TW icons do not use the "stroke" setting at the moment, we can add it. So using the stroke we can make our icons thicker and thinner. Depending on the stroke colour.

If the stroke is eg: black the icon becomes thicker. If the stroke is eg: <background-color> the icon will get thinner, as shown in my comment.

[mateuszwilczek]

Per @pmario's request I'm uploading a zip with the icons that I designed.
lucide-icons-wilk-2024-10-04.zip. These are unmodified InkScape files.

If in doubt which one was meant for what, see https://lucide-icons-wilk.tiddlyhost.com/

[pmario]

@mateuszwilczek I did already use some of them with the existing core set. Especially the line-width is creative and should be compatible to Lucide.

I'll add some of them to the origin directory. So we can experiment with them easily. We only need to create different sets of mapping configurations. So the sets can be built automatically.

[mateuszwilczek]

@pmario here's what I meant about the dynamic icons, the attached json contains dynamic save and network icons using Lucide icons:
lucide-dynamic.json
I simply replaced the shapes inside the respective svg groups with the Lucide icons (already outlined by your build process). It could be done similarly for the cloud icon if needed. This of course has to be done manually for each dynamic icon.
The dynamic save icon looks like this:
.
The dirty icon is lucide-circle-dot.

[mateuszwilczek]

@pmario some explanation that I forgot to add: I have added "lucide" class to the svg elements, but since they are composed of two different lucide icons, e.g. lucide-circle-check-big and lucide-circle-dot, I didn't put these icon-specific classes anywhere. I guess having both of them in the svg element if only one will ever be visible won't be useful. These specific classes could be added to the groups inside, but then this probably wouldn't be helpful a lot.

So these dynamic icons that I made diverge from the "rules" set for other lucide icons in TW a bit, but they look like part of the set now.

The cloud icon from the tiddlyweb plugin would also need to be manually created. The problem is, there aren't any exactly matching Lucide icons (and only cloud-check in Tabler), so these would have to be created. I could try to create these adhering to Lucide guidelines.

[Leilei332]

IMO the two icons in tabler.io can be used as the cloud icon. The cog in the first icon can be styled to spin to indicate tiddlyweb is saving.

[pmario]

@mateuszwilczek -- The main problem is "manual"

I do have 1 "manual" icon in the repo. The "new-journal" button. It creates a severe problem, whenever I do change something in the general SVG structure. Because I need to fix it manually :/

So -- It needs to be done with software. The repo already contains the SVGSON library, that allows us to manipulate SVGs as JSON objects.

This should make it much easier to load 2 icons from the Lucide set and create a custom icon, because it is easier to manipulate JS objects then a SVG DOM structure.

---

I am not happy with the "circle-dot" icon. I think the "dot" is way to small.

I did create the custom Close-Others button, which is part of the set already.

We could use this one and create a custom "circle-big-dot" icon, which will be never compatible with Lucide, since they can not do filled icons yet. -- This one may also end up as a special-icon. -- That's the main reason why I did not touch them atm.

[pmario]

@Jermolene -- Would you be happy with a combination of those 2 icons as a replacement of the web-save icon?

[pmario]

IMO the two icons in tabler.io can be used as the cloud icon. The cog in the first icon can be styled to spin to indicate tiddlyweb is saving.

@Leilei332 ... Did you try to animate the cog with CSS only already?

[mateuszwilczek]

@Leilei332 I saw these too, I think they are great for a quick temporary solution, but the cloud shape is different than the one used in Lucide. So if we'd like Lucide to remain the reference point and have all icons as close to Lucide as possible, we'd need new ones.

@pmario I know that the circle-dot is further away from the current dirty save, and that the close-others is closer.
I meant it more as a demo how it is possible to achieve a dynamic icon, even if manually at this point
I don't insist that circle-dot is the best choice here, it was simply the closest that's not already in use elsewhere.
Btw, I also don't think that the circle in circle is a good icon for close others button, something like lucide-crosshair (as in "focus") or something featuring an "x" would be better.

We could use this one and create a custom "circle-big-dot" icon, which will be never compatible with Lucide, since they can not do filled icons yet.

I don't see a reason for that, unless we absolutely want to keep the design of new icons as close as possible to the old ones. But we're not trying to do that anyway. I see nothing bad in changing the dirty save icon to something similar but not filled in. The only exception where I think we could use a filled in icon is the core star-filled, because of its unfortunate name.

The repo already contains the SVGSON library, that allows us to manipulate SVGs as JSON objects.

This should make it much easier to load 2 icons from the Lucide set and create a custom icon, because it is easier to manipulate JS objects then a SVG DOM structure.

This is great!

[pmario]

Btw, I also don't think that the circle in circle is a good icon for close others button, something like lucide-crosshair (as in "focus") or something featuring an "x" would be better.

You mean something like the "locate fixed" -- Would be worth an experiment.
https://lucide.dev/icons/?focus=&search=cross

[pmario]

I don't insist that circle-dot is the best choice here, it was simply the closest that's not already in use elsewhere.

As an experiment it's OK. But as I wrote. We will need to modify our "special" icons with code. Otherwise it will be very hard to maintain.

I don't see a reason for that, unless we absolutely want to keep the design of new icons as close as possible to the old ones. But we're not trying to do that anyway. I see nothing bad in changing the dirty save icon to something similar but not filled in. The only exception where I think we could use a filled in icon is the core star-filled, because of its unfortunate name.

The "dirty" icon has a special reason, why it looks as it is. -- Accessibility. For colour-blind users the old "circle check"-green or "circle check"-red was not good enough. So the new "circle-circle"-dirty indicator was developed.

[mateuszwilczek]

The "dirty" icon has a special reason, why it looks as it is. -- Accessibility. For colour-blind users the old "circle check"-green or "circle check"-red was not good enough. So the new "circle-circle"-dirty indicator was developed.

I understand why we want a different look for the dirty save icon. I meant that I don't see why we would want the dirty icon in the Lucide set to be a custom filled shape, rather than one of many possible stroke based Lucide compatible designs.

You mean something like the "locate fixed" -- Would be worth an experiment.

Any of the crosshair-like icons like the locate, locate-fixed, or crosshair, would be better for "close others" than the circle inside circle IMO.

[mateuszwilczek]

@pmario Is now the right moment to discuss the particular choices of Lucide icons for replacing core icons? You have shown that it should be easy to make such changes in your build process.
I think sometime before releasing the plugin as a core plugin it should be discussed, so that the new icons are chosen possibly similar to old ones and clear in meaning. But I wouldn't like to derail the discussion if there are more important problems atm. If now is the good time, what's the best place to suggest and discuss changes in choice of icons, here, in your plugin repo, or in the forum?

[pmario]

Currently I am creating the UI and the code to configure custom icon sets, that can be converted to plugins.
The configurations can be stored in the browser-storage, (TODO if users do decide to do so).

I think it should be discussed at: https://github.com/pmario/lucide-tiddlywiki-plugin/issues because it belongs there. At the moment the lucide-core icons are not included in the TW core.

We can create issues there on a per icon basis without a problem of spamming the TW-issues here.

The current icon-set can be reviewed at: https://pmario.github.io/lucide-tiddlywiki-plugin/
All icons can be seen at: https://pmario.github.io/lucide-tiddlywiki-plugin/lucide-all.html

I intend to publish the first version of the plugin-creator very soon.

[pmario]

@mateuszwilczek -- I did update the lucide-all version.

As soon as you click an icon in the Lucide Gallery, the right sidebar -> Icon Sets will open and will add icons to the set

You can play with it..

The next step will be to publish 2 core icons sets. One as it is now -- And one with your icons.

[pmario]

@mateuszwilczek -- See some new info at the gh repo: https://github.com/pmario/lucide-tiddlywiki-plugin and pmario/lucide-tiddlywiki-plugin#1