- The existing model already gives us a mechanism to separate presentation characteristics (font, etc) from structure (block hierarchy), and though it's currently not bidirectional, we could make it so if there were a need. I don't see the benefit in using Query to relate blocks to styles.
- Blocks aren't blind to styles, and wouldn't be even if we converted to your mechanism: CPIA isn't a browser where a presentation engine combines style information and a data description and generates a presentation -- each CPIA block is responsible for its own presentation, so each will still have to interrogate the style information as it does now.
- A block might need to know more than one style (for instance, a label font and a value font), or the colors to be used for different parts of what it's drawing -- your model appears to preclude this.
- The current separate characterStyle and colorStyle structures could easily be combined or made more generic, but again, what's the need?
- There are problems with the existing mechanism, like per-platform layout issues (font family & size defaults, margins, etc), but your proposal doesn't address them.
...Bryan
Alec Flett wrote:
A while back I posted about a proposal for applying styles to chandler. Here's my proposal:
http://wiki.osafoundation.org/bin/view/Chandler/VisualStyle
This would replace the current colorStyle, characterStyle, and so forth.
Alec
------------------------------------------------------------------------
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
