Generate icons from a font file

[stevemessick]

At a high level, the plan for generalizing icon previews is:

• Allow users to specify which packages contain custom icons; the IDE will handle Material and Cupertino automatically
• Use the analysis server to get the path to the package (analysis.getLibraryDependencies)
• Require the icon font file to be on a specific path in the package; ditto for the Dart class that defines constants
• Generate the name-to-codepoint map from the class
• Use the class in this PR to generate icons when needed
• Add a cache for icons since we won't be using IconLoader anymore
• Later, add package name completion to the UI that is used to identify icon packs

@devoncarew @jacob314 @DanTup

[DanTup]

Is this intended for a package author to generate files that will be included in the package, or for an end user to generate previews for packages they're using? If the latter, is there a way it could be done in a shared tool that each editor could use? (There are more editors using the LSP server, so anything done directly in the VS Code extension they wouldn't get the benefit of).

[stevemessick]

If it is fast enough, then the previews will be generated dynamically from the font. If the font I/O is too slow then they will be generated when the project is first opened and saved to the file system. IntelliJ doesn't need any analyzer support other than finding the path to the font package; it has its own AST that it uses to identify icon references.

[devoncarew]

Generate the name-to-codepoint map from the class

Who would do this step? I'm guessing that that info would have to live in a hand-authored file, and tools would use it?

If the latter, is there a way it could be done in a shared tool that each editor could use?

I think having each IDE responsible for generating the icons adds a level of difficulty to the IDE impl. One of the benefits of the https://github.com/flutter/tools_metadata project is that it lowers the amount of work and know-how that end user tools have to do to show icon previews.

What if we build a CLI tool that takes a well-formed icon font package and emits icon preview files into the right place (into the example directory, or somewhere else where the output would be packaged up by pub). Then the preview icons would ship with the icon package and be available on disk for IDEs to consume.

[stevemessick]

My goal is to minimize work required to display icons for 3P font packages. End-users shouldn't have to do anything, and package authors shouldn't have to do anything special if they are already following the conventions established by Material and Cupertino. All that I checked so far are.

Who would do this step? I'm guessing that that info would have to live in a hand-authored file, and tools would use it?

The plugin will generate that from the Dart file that defines icon names. Each font package includes a Dart class with icon definitions similar to this:
static const IconData airplane_ticket = IconData(0xe06d, fontFamily: 'MaterialIcons');
The name and codepoint can easily be extracted from that. A stand-alone tool could use a regexp; the Flutter plugin could use the Dart parser in the Dart plugin.

I think having each IDE responsible for generating the icons adds a level of difficulty to the IDE impl.

But that is where this support belongs. It's going to be a lot easier to convince IDE extension authors to add preview support than to get all font package authors to do so. I think it is unlikely that Material will add it because it will increase the size of the SDK (but I could be wrong, I have not checked with them about size increases). And then there are the font pack aggregators that include 15 or so font packs in a single package. Their distribution bandwidth requirements would be huge.

We don't need to distribute preview files with the plugin or with the font packs. Thanks to @dnfield for prompting me to take a deeper look at that option.

[helin24]

When is this single icon convert meant to be used? If the end user has a color hex in their code? If possible it would be nice to have a test for this method as well.

[stevemessick]

Yes, this is the entry-point for the plugin to use while IntelliJ is walking the Dart AST. We'd look up the name if an icon was referenced by name, to get the hex number, or get the number from the AST if it was referenced by codepoint.

[dnfield]

I agree that if there's any way to push this upstream e.g. to the LSP, it would be beneficial. But I also agree that it's not going to work too great to expect all font pack authors to run these generation steps for various IDE plugins to consume, unless we somehow build that into publishing a font package.

[DanTup]

Yep, it would definitely be nice to have this somewhere usable by the LSP rather than VS Code (if not by having the images in the package directly, at least allowing it to create them rather than the editor). For some LSP clients there aren't even Dart extensions, they're just end users configuring the generic LSP support in their editor to launch the Dart LSP server.

It would also be nice if they were visible in the online docs linked from pub (although perhaps that could be done using the font and not necessarily needing the images? 🤷‍♂️)