Philosopher wrote:@H: I was thinking of working on the styling a bit more - supporting that I think will be key for diverse uses. Once I start loading files by extension, we should be able to have say both a VOR-ND.symbol and a VOR-MAP.symbol yet use the same VOR.lcontroller. Similarly, styles and other options (e.g. radio or autopilot properties) should be doable, and I know we have stubs for these right now, it's a matter of using them.
Subject: Porting the map dialog for 3.2
Philosopher wrote:I'm even debating moving styles from layers to symbols maybe? That is where they are actually used, and would eliminate the ugly "me.layer.style" pattern. Adding helpers would be good.[/list]
Styling needs to occur better and files can usually be simplified.
Referring to the gitorious discussion about having a SVGSymbol class - that is something that will be hard to support/integrate with pre-defined styling unless we patch svg.nas to accept a list of optional SVG attributes that are mapped to a transformation/rewrite-callback so that SVG attributes can be dynamically "rewritten" by the parser based on looking up a certain id and changing CSS stuff there.
For instance, imagine a 2D symbol depicting an ILS (could only find a 3D view):
This could then use id settings like "glideslope" and "localize" to make those elements accessible, the parser would check its lookup map if the current element matches any key, and if so applies the callback to rewrite the corresponding tag to transparently re-style things without having to modify the actual file. People wanting to change the representation would then merely need to copy the SVG file and ensure that they use the same IDs that are required by the layer's style