Temporary KColorScheme change - hard-code some state colors

[Inge Wallin]

On Sunday 16 September 2007 12:59, Jos Poortvliet wrote:
> On 9/16/07, pinheiro <nuno at oxygen-icons.org> wrote:
> > A Sunday 16 September 2007 11:23:00, Tom Albers escreveu:
> > > Op zo 16 sep 2007 12:15 schreef u:
> > > > Think i will replay everytime so I get myself listen and understod
> > > > about that.....
> > > > You are confusing a feature that can go all the way into that maximum
> > > > difrence to a defoult that will be barly visible. The control UI is
> > > > not done yet soo right now its in maximum values so we could test
> > > > it........ ofcouse it loks ugly and unaceptable its in maximum
> > > > values.
> > >
> > > Yes, sorry I missed that bit and that you had to repeat yourself, but
> > > we are close to a release, we can not test anymore, we must finish
> > > things. So please adjust the value to a reasonable default, so that the
> > > beta releases we are making actually make sense to our users.
> > >
> > > Toma
> >
> > Yes but frist the pallete must be fixed no point on fixing somthing that
> > is dependent on another one that is broken...
>
> Let me propose to let the artists and usability people figure this
> out. Let matthew and Pinheiro play. If we don't like the END RESULT
> (and please stop stop stop bitching about the current look, as it's
> simply NOT meant to look that way) it will SIMPLY be a matter of
> changing a DEFAULT color scheme setting. Don't tell me that's a huge
> issue, stability-wise, cuz I don't believe that.

Let me just add that for thin clients, changing large parts of the GUI just 
because of a shift of focus is a complete no-no!  Some things are nice 
conceptually and maybe even usability wise, but yet completely impossible for 
technical reasons.

Last week I was in Brazil and at one time doing a test for a medical 
organization.  They have a large number of smallish sites and they want to 
run the computing infrastructure from a central data center. Right now they 
are deciding between Linux and Windows and the one most deciding factor is 
the bandwidth consumption. If more than just the tiniest change is done when 
the user shifts focus, Linux is out! 

I picked this case out of many, so don't tell me this is an atypical example. 
Bandwidth is not a universal resource all over the world. We are not just 
designing KDE4 for the last generation of fat clients. We also have to take 
into account thin clients and older or cheaper desktop computers.

Remember that thin client installations mean large installations.  You 
wouldn't want to make KDE impossible in these large installations, would you? 
(and no, I'm not directing this to you personally, Jos, just to 'you' in 
general.)  Design is good, but it always has to work inside the frames 
created by available technology and cost considerations.

	-Inge

-- 
Inge Wallin               | Thus spake the master programmer:               |
                          |      "After three days without programming,     |
inge at lysator.liu.se       |       life becomes meaningless."                |
                          | Geoffrey James: The Tao of Programming.         |