Temporary KColorScheme change - hard-code some state colors

[pinheiro]

A Sunday 16 September 2007 13:41:03, Inge Wallin escreveu:
> 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

Best argument so far..... could we disable such a thin clients automaticly?

-- 

core oxygen icon designer