Bryan Stearns wrote:
(Alec and I had an in-person conversation about this, but he suggested I include my feedback in the discussion...) Bryan's feedback has made me realize I left out a key component of the proposal... the "Why?" - but the good news is that he made me really think back to the original reasons for proposing this, and think about what other solutions would be feasible. I've added new sections to the document: "Goals" "Simpler Solutions" and "Baby Steps" as well as giving more information (i.e. examples) for per-platform and per-locale style issues. - 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.Yeah, Query was probably overkill but was more to just serve as an example.. the 4 examples are more or less in order of importance. I guess my biggest objection to the current mechanism is that block authors have to even think about presentation, and should instead inherit it from the rest of the system. A simpler proposal might be to simply get specific about our style names with respect to their purpose, rather than what they are - i.e. instead of the detail view's statictext labels might point to a "detailViewLabel" style rather than "LabelStyle" and so forth. - 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.well the interrogation would be done in the style, not the other way around. Each CPIA block would no longer be responsible for its presentation, it would just delegate to the style system which would generically apply these attributes to the appropriate blocks. - 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.You're right.. I guess I always think of blocks as being at the widget level... i.e. blocks usually correspond to widgets - but its true that the don't always apply. - The current separate characterStyle and colorStyle structures could easily be combined or made more generic, but again, what's the need?Mostly because I don't see the need to combine them. I think of style as being a group of attributes (font, border, margin, whatever) to apply to a specific part of the UI... i.e. the style that applies to lines in the summary view. I think its just extra work for a developer to have to have to declare each of these things separately. - 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.Ah! I should add that - this was actually part of the plan. I've added this to the document. Alec |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
