we should have a different mechanism for color preferences, probably tied into workspace or optionally project-specific eclipse preferences, instead of the current color.def.
We should also have a nice mechanism for specifying color rules, with color pickers and such, and instant effect upon save. At a first instance, only the color labels used in custom displays are targeted (not the built-in colors such as alarm-sensitivity borders).
The suggest approach would be better than the current approach which has these issues:
color preferences are a 'file' within the workspace, and a link to that file has to be hardcoded in the workspace preferences. This is a common cause of confusion, as people import projects without the workspace preferences (to research whether suggested solution solves this -- but the assumption is that we can store metadata under project/.settings)
Currently we can have only one color file per workspace. Which is not only annoying, but also weird when one project is using the color file of another project.
Color/font preferences are now directly managed in workspace references (rather than indirectly via .def files). Maybe we add optional project-specific scope in a future release, but no immediate plans.
we should have a different mechanism for color preferences, probably tied into workspace or optionally project-specific eclipse preferences, instead of the current
color.def
.We should also have a nice mechanism for specifying color rules, with color pickers and such, and instant effect upon save. At a first instance, only the color labels used in custom displays are targeted (not the built-in colors such as alarm-sensitivity borders).
The suggest approach would be better than the current approach which has these issues:
project/.settings
)