[RFC] New Lucide Icon Set Plugin - Intended to be a core drop-in replacement

Hi folks,

This is a request for feedback (RFC)

I did just push an experimental plugin to GitHub, that is intended to be a “drop in replacement” for the core icon set. It is possible, that this plugin can be shipped with the TW core.

Experimental Demo: Lucide Icons — Lucide v0.452.0

All 1500++ icons: Custom Icons Edition — Based on Lucide v0.452.0

At the moment the core replacement plugin contains 106 icons.

  • 65 icons directly come from the 1531 Lucide icons
  • 41 icons are unique to TW and have been replicated in a Lucide compatible way.
    • It is intended to contribute some of them to the upstream project (if they want them ;).

Differences Between Lucide default- and TiddlyWiki default-icons

  • Lucide icons are stroke based. That means they do contain lines only. There are no fillable areas.
  • TW icons are path based. That means every line is an area, that can be filled.

Both systems have their advantages.

  • Stroke based icons make it easy to define stroke-width with CSS
  • Path based icons make it easy to use fill and CSS to control colours and other parameters

Due to these fundamental differences Lucide icons have to be converted to a path format, that TW can use efficiently.

TW uses wikitext within icons, like \parameters, specific classes like: class="tc-image-button" ... and so on. Some buttons are dynamically changed based on CSS state variables eg: The core save-button. …

\parameters (size:"22pt")
<svg width=<<size>> height=<<size>>
    class="tc-image-chevron-left tc-image-button"
    viewBox="0 0 24 24" fill="currentColor" stroke="none" stroke-width="0"><path /></svg>

I did convert the missing 41 TW icons, with help from the community, to a format that can be easily changed using the InkSkape SVG Editor.

Once saved a build-system can be started that programmatically does convert the “stroke” based icons into tiddlers, that contain our “path” based icons. Including backwards compatible TW titles, tags, class and parameter definitions.

The build system creates a plugin and the demo-edition.

Next Steps

In no particular order

  • [ ] Make path-width configurable to create a similar experience as with dynamic stroke-width
  • [ ] Create a TW Edition that contains all Lucide icons
  • [ ] Implement interactive search into the Edition using the meta data from the upstream project

Request For Feedback

Feedback here or at: Adopt Feather/Lucide icons · Issue #7652 · TiddlyWiki/TiddlyWiki5 · GitHub

Exploring the Lucide icon set can be done at: Lucide

  • What do you think?
  • It is relatively straight forward to include missing icons into the Lucide-plugin
    • So if you desperately need something have a look at the Lucide page

Before you start to request completely new icons. Here are the rules: Icon Design Guide | Lucide

have fun!
Mario

PS: Just to let you know. Including all 1500++ icons into 1 plugin does not make much sense. It will be ~4MByte in size.

6 Likes

My feedback starts with a question:

Why do we think Lucide is the way to go? ~1,500 icons is a small pool of choices. I typed a few tryouts in the search box and was less than enarmoured with the results on offer. “filter” was a particularly poor offering.

@pmario I appreciate the work you’ve put in here, but I confess, I had it in mind that Lucide would offer a wealth and plethora of opportunities. From this showing, I realize I was mistaken.

Generally I like these icons, in an initial test a couple of things I didn’t love (being nitpicky)

  • The close X is noticeably thicker
  • The + is pretty small (compare home to plus)

These are definitely more “modern” looking which is a nice upgrade.

Before (above) and After (below)

Thanks for your feedback.

Thechnically, that’s not the case. It is line-width 2px. So that’s an optical illusion.

That’s right. There is no Lucide plus-big at the moment.

Thanks for the feedback.

What are the alternatives?

  • Where do we have a similar amount of icons?
  • Where is the license compatible with our TW BSD 3-clause?
  • Where do we get the code of a full build system, that allows us to build every icon from scratch?
  • Where do we have the possibility to create our own compatible icons in an easy to create format?
  • Where do we get code that will allow us to convert “stroke icons” into “path icons” which we need for backwards compatibility?
  • Where do we get icons that actually look good and are modern?
  • Where do we get consistent and easy to understand guidelines how to create new icons?
  • Where do we get an active project, that constantly adds new icons in an understandable way?
    • In May as I did look the first time, there where about 1300+ icons. Now there are 1500
  • Where do we get the possibility to contribute, if we deliver quality?

At the moment we do have ~100+ icons in the core. So 15 times more is not that bad. I did need to create some custom icons, because they did not exist upstream. But there is a chance that some are accepted uptream.

The term: “filter” gives me 20 results

  • What would you like to have?

There is a Lab checkbox. If you switch in on there are 400 icons more in other categories. (But I’m not sure yet, how we can use them. )

Icon naming is a bit strange. Tags and categories may not always work out. But they have a rule for icon naming too. Icon Design Guide | Lucide which may help with finding the right search terms.

Yea, There is a crux with expectations. Sometimes they make me feel sad.

Thank you for the detailed response. I’ll defer…

Looking at the proposed icons, I prefer at least 90% of them to the current ones.

But when I look at the in situ, as with @stobot’s screenshots, it becomes a little less clear to me. The “after” page looks a bit cartoonish. I’m sure I’d get used to them, and overall I’m still in favor, but not as enthusiastically as when I first viewed them.

Two questions:

First,

I know little about SVG. Does that mean we can’t color stroke-based ones?

Second, how much would this break backward compatibility for wikis that are formatting the current icons? Do we have any way to know?

Are these intended to replace the current icon set (as Jeremy’s first post in the GitHub thread suggests) or simply as a core-compatible alternative for those who want them? While I appreciate the work you’ve put into this, I really prefer the look of the current icons. I can’t envision many instances in which I’d want to adjust the stroke width, whereas I do frequently use fill to adjust colors. And most importantly to me personally, I’ve been adding filled icons (from TW Icons and other libraries) specifically to match the style of the current core set, and I’d prefer not to mix the stroke- and path-based styles.

As an optional plugin, though, I think it’s great! We’ve already got theme, palette, and storyview options; it seems natural to offer icon set options as well.

Okay, with a little more digging, I found these: https://www.svgrepo.com/

I think someone posted this site recently? They claim to host 500,000 SVGs. I don’t know if that’s true, obviously, but when I searched for…

Filters: 12 (TWELVE!) pages (50/page). Full marks for hi/lo/band-pass filter icons! Filter SVG Vectors and Icons - SVG Repo

I don’t know enough about licensing to answer, but I did find this:

https://www.svgrepo.com/page/licensing/

And as for tools… Free SVG Tools - SVG Repo

Honestly, when it comes to offering a good source, 1500 is tiny (and honestly, a growth of ~200 in 1/3yr isn’t very inspiring). I just know I’m going to have limited choice when it comes to a specific icon-need.

The base icons are stroke based. They can be coloured, but in a different way as our system works at the moment.So they would not be 100% compatible. But the scripts that I did create, convert them in a way that makes them 100% compatible. The new icons work exactly as the old ones. They only look different.

If you used CSS to format the current icons, the new ones should be 100% compatible. If you did modify the icons, the new icons can be modified in the exact same way.

The new icons are 100% compatible with all existing wikis >= v5.3.x

It should be possible to create a plugin, that is compatible with v5.2.7 down to v5.1.0 – I only need to create it.

2 Likes

https://iconify.design/ Here are some commonly used icon sets

2 Likes

They are intended to become a drop-in replacement plugin, for those who want them.

There is no mixing going on. The advantage of stroke based icons is, that they are incredibly easy to create and modify, in a consistent way. The code that I wrote will convert them into the exact same format as we use at the moment.

So if you used icons from other libraries, that’s OK. – The plugin is optional.

1 Like

@oeyoews … Thx that’s a nice overview. I do like Phosphor and Tabler. They have the right license and seem to have a reasonable software stack.

Phosphor lists 9072 icons, but they split them into 6 versions. So 1 set has 1512 icons.

Tabler lists 5650+ icons and seems to work with the same templates as Lucide – It seems the icons are unique. – I think I can use them with the same build-stack that I’ve already created. The directory structure is different. – We’ll see

@oeyoews

https://iconify.design/ Here are some commonly used icon sets

Thank you for sharing this. Iconify is very rich and can be used for selecting a good set for TiddlyWiki.

@PMario

I would suggest any set selected can act as an alternative. So, user can select between different sets of icons for their edition.

I realize, now, much too late, this is not a proper RFC. There’s no debate to be had after reading Adopt Feather/Lucide icons · Issue #7652 · TiddlyWiki/TiddlyWiki5 · GitHub in full.

I am confused. Why is it an improper RFC?

It is a “request for comments” about, what the community thinks about a plugin that is introduced. This thread clearly shows, that there is some discussion going on.


I did visit svgrepo.com and https://iconify.design to see, if there is something we can use, using the criteria I did post at my previous comment.

Licenses are important, if we want to use 3rd party icons for the core. We need MIT, BSD or an other open source license that is compatible with our BSD 3-clause license.

For a full icon-set we need a replacement that is consistent in visual appearance. Mixing icons from different packages is not really possible for the core. It is not consistent.

It is nice to have 500k icons, but we also need them to be accessible with a version control system, so we can track and process them programmatically.

We need to convert them to .tid format and add some wikitext, like \parameters, width=<<size>> and TW specific class=".." definitions. Especially we need to map icon-names to our TW system-tiddler titles to be backwards compatible.

All of that needs to happen programmatically to make it reasonable to maintain.

Perhaps I wasn’t clear enough. The “debate”, “discussion” and perhaps even the “decision” has already been made. After catching up with the conversation on GitHub, I realized I wasn’t seeing anything like “should we?” “could we?” “are we doing the right thing?”. After @jeremyruston’s supportive comments, the conversation shifted quite quickly to “how?” not “should we?”.

So, in that sense, asking for comments here, using “RFC” in the conventional sense, is way, way, too late, since this is, IMV, a 99% done deal. This is more, “we’re doing this, what do you think?” which is not how “RFC”, by convention, is typically used.

Hope that’s clearer.

And PLEASE don’t take this as a put-down. It’s a meta-comment about procedure and protocol.

My only real feedback (in terms of the whole idea) is, 1500 icons is a paltry offering.

And I repeat: Thanks for the work you’ve put in. Having read the entire GH thread, I’m aghast at the diligence :clap: ← seriously.

@pmario

  1. I like the icons you’re demoing
  2. How does a “core drop-in replacement” differ from a plugin?
  3. I’ve previously expressed that TW should, in additon to its special icons, feature a limited set of very generic icons here, for the sake of hackability.

There is no difference it is a plugin, but it should be 100% compatible with no side effects. It means that it should be consistent and if possible cover every icon. – Except those, that are completely filled. There are no real alternatives at the moment.

It is intended to create an edition that contains all available icons.

The Lucide repository contains a lot of icon meta data, that can be used for searching.
In a next-step I intend to use that info in TW so we can use it there too.

Is “edition” the right term here? I have come to understand “edition” to mean a TW setup intended to be downloaded/used as a whole. It will be significantly more useful you make a public TW that serves all icons so one can pick individual ones :slight_smile: (like @morosanuae 's tw-icons)

Regardless, thank you! I think this will all end up to be very useful.