kwin clients - virtual colorsSupported()?

[Matthew Woehlke]

Lubos Lunak wrote:
> On út 27. listopadu 2007, Aaron J. Seigo wrote:
>> On Tuesday 27 November 2007, Matthew Woehlke wrote:
>>> Ok. aseigo and I talked on IRC, and came up with two recommended
>>> solutions:
>>>
>>> 1. add color types to Ability
>>>    + no new API, BC
>>>    - all clients must be updated or result will be wrong
>> the reason for "result will be wrong" would be code in a client that has a
>> switch statement like this:
>>
>> switch (ability) {
>> 	case $SupportAbility:
>> 	case $AnotherSupportAbility:
>> 		return true;
>> 		break;
>> 	default:
>> 		return false;
>> }
>>
>> obviously that would result in no colour settings. i don't know if such
>> code is common in kwin clients, but i can see that happening rather easily.
> 
>  There would be a flag saying whether the client supports announcing it at 
> all. If it's not set, do whatever should be the (backwards-compatible) 
> default.

...which means that we need a wrapper API if other programs (i.e. the 
kcm) are going to have a nice way to query the client. IOW, I would much 
prefer 2a to this, the only caveat of course being B(I)C.

>>> 2a. add 'virtual supports(ColorType) const;' to KDecorationFactory
>>>    + reuses existing enum
>>>    - BIC
>>>    - clients might forget to override it
>> at least this is easy to notice (colours set aren't used) and the worst
>> case scenario is that we have the same problems we have now. so no
>> regressions and with a way to fix the current bug at our disposal, without
>> having to touch every single client either.
> 
>  In this regard this seems to be the same like 1., with "+ there's only one 
> place for specifying abilities".

Lubos: what did you think of 2b? (I still (also) like the cleanness of 
being able to reuse the existing ColorType.)

-- 
Matthew
"Still not King." -- Aragorn
(as quoted in The Very Secret Diaries by Cassandra Claire)
http://www.ealasaid.com/misc/vsd/