color roles: requesting kdelibs policy exception (answer June 11, please!)

[Matthew Woehlke]

Simon puts me in a difficult spot... :-)

Currently, his (1) is the only objection to the color roles stuff (2) 
going in today, and the problem is... I agree. Mostly.

Here's the thing: The usability folks would really, /really/ like this 
to go in today because hard-coded colors are the slated to be the week's 
usability topic. It would be nice if we had the solution ready :-).

As I said, the more I think about it, the more I'm inclined to agree 
with Simon about putting this stuff in its own class. However... I'd 
really prefer to name it KPalette, since it will actually be a KDE 
version of QPalette. (Making this change is debatably a policy violation?)

Unfortunately, we already have a "KPalette" that has nothing to do with 
QPalette. aseigo and I talked about renaming this to KIndexedPalette 
(this is where aseigo gets to yell at me for not bringing this to list 
sooner... sigh, 20/20 hindsight). However doing it today (without one 
week notice) would be a kdelibs policy violation.

So, as I see it there are a couple of options...

- Do nothing, disappointing the usability people.
- Leave stuff in KGS and move it next week
- Put stuff in KColorTheme and live with that name
- Put stuff in KColorTheme and rename it next week
- Put stuff in KPalette after renaming the other KPalette

The first two options are IMO not desirable. The last one is a definite 
policy violation (I'm not sure about the third and fourth; how does the 
policy apply when someone asks to alter a proposal?).

Suggestions?

1: http://permalink.gmane.org/gmane.comp.kde.devel.core/43021
2: http://permalink.gmane.org/gmane.comp.kde.devel.core/42965

-- 
Matthew
Ngx iqct zgg dxei zodt gf ngxk iqfrl.