kwin clients - virtual colorsSupported()?

[Aaron J. Seigo]

On Tuesday 27 November 2007, Matthew Woehlke wrote:
> Lubos Lunak wrote:
> > On Tuesday 27 of November 2007, Matthew Woehlke wrote:
> >> aseigo and I have been having a little discussion [1] about kwin colors,
> >> the upshot of which seems to be that kwinclients should communicate what
> >> colors they support, similar I suppose to how they report what buttons
> >> they support.
> >>
> >> Without knowing kwin very well, my gut reaction is that the "best" way
> >> to do this is with a pure virtual, which means making the change *now*
> >> since it is BIC+SIC. (aseigo says a getter+setter can be done BC but
> >> agrees that a virtual is probably better.)
> >>
> >> Lubos, your thoughts?
> >
> >  If all you need is querying a decoration whether it supports something,
> > see KDecorationFactory::supports(). This is already done for buttons -
> > there's one flag for querying whether the client supports announcing
> > supported buttons :) and then there's one flag per button. You can have
> > the same for window roles.
>
> 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.

> 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.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071127/6ba9cc27/attachment.sig>