kwin clients - virtual colorsSupported()?

[Luciano Montanaro]

Il Tuesday 27 November 2007 18:24:51 Matthew Woehlke ha scritto:
> Luciano Montanaro wrote:
> > Il Tuesday 27 November 2007 17:56:08 Matthew Woehlke ha scritto:
> >> 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?
> >>
> >> 1: http://permalink.gmane.org/gmane.comp.kde.devel.general/51132
> >
> > I'm not against it, but I'm not sure kwin decoration ABI is really
> > considered unchangable. After all, it affects only decorations which tend
> > to be non-critical and mostly shipped with KDE.
> >
> > So I'm not sure we should really rush things.
>
> If it's OK for kwin to break BC, then I'm all for waiting for 4.1.
> Otherwise, what I am envisioning is basically something that returns an
> enum list (I guess good old QFlags, i.e. 31 values will be enough*),
> which can start out as the basic colors we know we will have, and be
> grown in a BC way. Nothing complicated, nothing I'm too worried about.
>
> (* Especially if we make Inactive a single flag, i.e. "yes I know the
> difference between active and inactive windows", implicitly requiring an
> active and inactive flavor of each WM color role.)

Oh, and we already have a mechanism to query KWin decoration for the supported 
abilities: the Decoration factory has a supports() methods that returns true 
if a given "Ability" is supported. So we could just add color roles as 
abilities.