It would be probably be more beneficial in the longer term when there are more themes.
If the getXXXColor method just returns a hard coded colour (albeit supplied by the theme designer) for use with a ShadeDecorator then we might still have problems. Any styles that the user may have specified might also render (apologies for the pun!) the chosen colour ineffective for highlighting purposes. Perhaps stick with the ShadeDecorator, but swap it out for another Decorator later should the need arise? Chris On 25 September 2010 01:22, Greg Brown <[email protected]> wrote: > Another option just occurred to me that might work well - you could get the > debug focus color from the theme. That would avoid the potential contrast > issues, and would still allow us to use "debugfocus" as the property name. > > In order to do this, we'd just need to add a new abstract method to Theme, > such as getDebugFocusColor() or getDebugHighlightColor(). > > What do you think? > > On Sep 24, 2010, at 1:54 PM, Greg Brown wrote: > > > I don't want to be needlessly nit-picky. I myself would probably just use > a shade decorator (or perhaps a hypothetical border decorator) with a fixed > color and call the flag "debugfocus". But if you prefer the choice of > colors, I am fine with that. > > > > On Sep 24, 2010, at 1:38 PM, Chris Bartlett wrote: > > > >> On 25 September 2010 00:10, Greg Brown <[email protected]> wrote: > >> > >>>>> Also, as a user, I think I might find it odd that I need to specify a > >>> color > >>>>> when really I just want the debug focus behavior. > >>>> > >>>> I'm not sure I agree that a user would find it odd if the property was > >>> named > >>>> debugfocuscolor and the documentation specified that it accepted one > of X > >>>> values to give them flexibility. > >>> > >>> As a user, I'd first expect to see a flag that enabled debug focus > >>> behavior, and then possibly an optional flag to control the color. > >>> > >> Having made the call to offer a choice of colours, and that the 'debug' > >> behaviour would be off by default, having 2 properties seemed overkill. > >> In other situations, of course what you are saying makes sense. > >> > >> > >>>>> Also, as Sandro pointed out, any hard-coded color may work well in > some > >>>>> schemes but not in others. > >>>>> > >>>> Hence 3 colors. I was aware of the work that you and Sandro had been > >>> doing > >>>> on different color schemes. > >>> > >>> Right, but the issue isn't color - it's contrast. That's why XOR mode > would > >>> help. It always draws in a contrasting color. > >>> > >> Yep, I understand. Again I was just trying to keep things simple while > >> offering some flexibility. > >> > >> Shall I continue with a ShadeDecorator, or would you rather something > else? > > > >
