metbril / openhab-mdi Goto Github PK

Currently there are multiple config files for multiple sets. I personally don't see an advantage of having to maintain multiple files (e.g. changes I suggested in #5) over not generating all icons (Unused icons don't hurt the user, when he has them).

What do you think?

The interpreter of mdi.py is #!/usr/local/bin/python3. You should change it to #!/usr/bin/env python3, so it works independently from how and where python is installed.

The GPL and EPL licenses are incompatible. If you want to enable code reuse by the OpenHAB project, I'd propose to reconsider relicensing to the EPL license. Relicensing might get more complicated as soon as there are relevant contributions of other contributors, as you'd have to fetch their agreement individually or remove the contributed code.

Hi,

I have a few suggestions:

• Add background templates (circle, square, etc.) and a command line option, e.g. --background circle.svg
• Add command line paramter to overwrite background and icon color. When you want to have colored backgrounds it might be a good idea to set all icons to black or white without the need to change .yaml files
• After this is done we could try to add several material themes (black icons with no background, icons with circle background, etc.) to ESH or openHAB

Run the script directly from the command line.

Having downloaded the icons is now a pre-requisite. Include downloading the repo in the script.

If the folder where the generated icons are written does not yet exist, the script fails.

Current workaround is to manually create the folder first.

Have the MDI icons as a submodule.

Some icons in the classic iconset are still missing in the MDI repo. During generation there are 2 options: use a stub icon that is used for any missing icon in the iconset or don't create an icon at all.

The current script supports this by defining icons (or not) in the yaml file. But perhaps we could add some configuration and a command line option to choose.

For example:

--missing help

for using the MDI help icon for any missing icon

The classic iconset has icons for parent with dual skin tones. E.g. the man and woman have the same or different skin colors.

The script can only apply one color per icon and no gradient.

Since it's material design icons, we should go for material colors: https://material.io/guidelines/style/color.html

The python script fails with a UnicodeDecodeError when reading the SVG files for some reason:

Copy /home/jenserat/src/openhab-mdi/download/MaterialDesign/icons/svg/playlist-play.svg to /home/jenserat/src/openhab-mdi/iconset/mdi/playlist.svg
Replace icon color with #000000
Traceback (most recent call last):
  File "./mdi.py", line 231, in <module>
    main(sys.argv)
  File "./mdi.py", line 209, in main
    svg_replace_fill(dstfile, '#000000', color)
  File "./mdi.py", line 21, in svg_replace_fill
    for line in file:
  File "/usr/lib/python3.5/fileinput.py", line 248, in __next__
    line = self._readline()
  File "/usr/lib/python3.5/fileinput.py", line 362, in _readline
    return self._readline()
  File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xef in position 0: ordinal not in range(128)
FAIL: 1

I propose using ElementTree and XPath as a proper solution for manipulating SVG files (which are well-formed XML files and thus are better manipulated using XML-native libraries instead of running sed-like plain text editing anyway). I will propose a change that resolves this issue by replacing the whole function in a few minutes.

Have the script generate anything and everything that is required for using the icons as an additional iconset in the Eclipse Smarthome repository

The color scheme could be included with the icons yaml file, but this would be less flexible (to generate a personal flavor.

Other option is to have a separate config file per color scheme (.conf of .yaml) that is parsed during execution.

A third option is to set the colors through the command line. This is a lot of hassle, so the least favorable.

For now, I am thinking of option 2, a separate .conf (simple ini file type or json) configuration file type, that can be parsed as a command line parameter and defaults to mdi.conf.