 |
Home | Changes | Index | Search | Go
Conceptual addition: Highlighter properties should be LF-dependent
This was part of a post in the SwingLabs Forum:
Highlighter overhaul under way ... feedback needed!
(The following is a summary of intensive discussions with our visual
design/usability experts, Coleen and Ann - all errors in summarizing are
produced by myself, of course 
AlternateRowHighlighters in particular have a useability task: help
users to quickly take in what's in the same row. This should be done in
an eye-pleasing manner.
Visual design results
- we call the "darker" background color the "striping" color (the lighter is the same as table background? white? focushighlightBackground?)
- selection color should be the same as without alternate row highlighting for all rows
- striping color should "merge" with current color theme
- one variant of "merge" is to use a striping color that works well with all (many?) color themes - that's a generic gray.
- another variant of "merge" is to relate it somehow to the selection background - overview for common LFs/themes
Implementation details
- added an interface UIHighlighter: it has a method updateUI which should be implemented to get LF specific properties. Note to myself: this might be a more generally applicable - maybe change name to something like UIUpdater?
- changed HighlighterPipeline to implement the interface (guarantees to updateUI for all contained highlighters)
- changed JXTable to updateUI of highlighters in updateUI
- added a first rough cut of UIAlternateRowHighlighter - which simply has a map of all known selection colors to striping colors as recommended by Coleen. This needs to be moved somehow into the LF
- added a AlternateRowHighlighter.genericGrey
Demo
The current state can be seen in the SwingXDemoLF in the swingx_dev demo package - it's the same as the SwingXDemo plus ability to switch LFs at runtime (with all the know liabilities)
Feedback in the discussion
- basic Highlighter implementations should come in two variants regarding color "computation"
- work well with LF dependent colors - choose them all automatically as deemed "nice-looking" in the context of the LF
- strictly apply the color properties of the highlighter as set by the developer, without trying to do some "clever" derivation behind the scenes.
Links
|