Closed smithed closed 9 years ago
The problem with that would be that it could find more .png in other folders, we still need a way to specify which ones are class glyphs. 2 simple options would be add a prefix to them and the search functions add all the .png with the cg_*.png the other option would be the classes as their property include the complete glyph path. The advantage of this is the path folder is no longer required and the path directory would be generated based on the properties (we are already searching for the classes, we don't need to make 2 searches).
if its path it would have to be relative path so itd have to be path relative to the class so it might as well be the way I described. I'm not sure why people would be including more PNGs in node folders, but your prefix rule would be OK.
Another option would be to have the node provide the raw image and the parent class provides it by name. This would leave backwards compatibility OK but also make it easier for people to plug in their own images by embedding the bitmap into their code.
Finding it automatically on disk next to the node has been extremely nice for tbdf. That said I think providing the raw image might be safer. It would work no matter how the node was packaged (like in a ppl or other format) and no matter what other .png files are loaded or stored in that directory.
One of the issues here, is we initialize the glyphs at a different point that the classes, so it would change how it load. Now one of the things is at least in platypus we are not using the raw glyphs, we are modifying them to add the x for invalid.
well that is another option, we could manage the glyphs in an FGV and if a class gets added which requests a glyph we haven't already added to the system, we can use some search paths nonsense to find it. I mean, theres no reason to cache all the glyphs on start, right?
similar to tbdf makes it easier to package/distribute classes. editor glyphs folder should be a default library sort of like lv icon editor.