NISystemsEngineering / CEF

A starting point for creating a custom configuration editor in the LabVIEW Development Environment.
https://decibel.ni.com/content/docs/DOC-37225
Other
14 stars 5 forks source link

Refactor CEF glyph loading process #26

Closed smithed closed 9 years ago

smithed commented 9 years ago

similar to tbdf makes it easier to package/distribute classes. editor glyphs folder should be a default library sort of like lv icon editor.

becega commented 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).

smithed commented 9 years ago

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.

Beazurt commented 9 years ago

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.

becega commented 9 years ago

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.

smithed commented 9 years ago

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?