Closed MsXam closed 2 years ago
ziofat
commented
2 years ago It should not change the icon point when new version releases. As in the latest version it only adds new icons. https://github.com/ziofat/material_design_icons_flutter/commit/d02b71a31e073b172c9bcd3d1eb521d5a9dd2b61 Your screenshot refers two major versions which have breaking changes in between.
MsXam
commented
2 years ago @ziofat Thanks for the confirmation - yes, I am updating a few apps that have the 14 month old plugins of material_design_icons. and only checked those versions with the latest release.
So to confirm, if we now adopt 4.0.5955 of your plugin, any new icons that are added will not change the icon point value of existing icons that we use from this version forward , correct ?
ziofat
commented
2 years ago For 4.0.x, yes. But we are expecting a 5.0 version which will introduce null safety and new icons comes from Material Design Icons. The code point cannot be guaranteed to remain same in new 5.0.x version because this will be controlled by the font library. And here is the expecting change list.
Templarian
commented
2 years ago For context (MDI maintainer) in 4.x+ we made the decision to start from F0001 as the previous F001 is a landmine of reserved codepoints after 4000 icons and caused issues on random devices. Rather than fix a few and skip random codepoints we decided to reset them all.
Codepoints are fixed for the most part, but still need to be careful with major version upgrades (especially 6.x where we did cleanup).
As always don't use the webfont. There are better options for the web. https://dev.materialdesignicons.com/guide/webfont-alternatives
Is there a way to preserve the values for the icon keys that you store in icon_map.dart ? It seems that each new release of this plugin - keys change values which will result in misleading and incorrect icons being displayed in apps that use this plugin.
Use case :
Thus, if the unicode integer value is stored and you then give a completely different value to a key that an app has previously persisted you end up with incorrect icons being shown.
A code solution I appreciate that one can store the keyname but doing so in this way will 1) prevent tree shaking and 2) incur more in terms of cloud costs since strings incur more overhead than ints in cloud firestore.
To insulate against this problem, when you use one of the 3rd party apps/websites that creates a TTF from an SVG - one can specify a starting offset position as the basis for creating a unique unicode value. All we need to do is ensure that the unicode offset position is 1 more than the last icon unicode value in icon_map.
This assumes that values in icon_map are sequential.