Hi,
Am Samstag, den 04.03.2006, 20:58 +0200 schrieb A.J. Venter:
> > > The default should always be to follow the theme, the programmer should
> > > think five or six times before overriding it - but when he does, it must
> > > be assumed that he had a good reason and his changes should be honoured.
> >
> > Exactly.
> >
> Let me try to explain what I mean with an EXTREME example.
> Say you are coding the control system for a nuclear power station. Now 99% of
> your screen is showing the current values for things and with some sliders
> the operators can adjust some of the equipment settings to ensure that
> everything remains normal.
>
> For almost all times this is ALL there is to it. But there on one side is a
> few critical values, these ones won't just be changed by adjusting one thing,
> if they are outside tolerance values then that means a trained expert will
> need to adjust probably 80% of those sliders to very specific settings to
> deal with what is in fact an emergency.
>
> So when one of those goes out of tolerable range you start by activating
> every
> alarm in the building, syrens howling, strobe lights flashing the works. But
> on screen you do NOT want everything highlighted. What you DO want is for the
> area around the specific value that triggered the problem to start cycling
> through red-green-blue-orange-purple and some more colours at a fairly high
> rate so the operator your alarm woke up will INSTANTLY see which value is out
> of range and can start fixing it immediately.
> You don't want to pop up a dialog - clicking ok means it takes longer before
> he starts adjusting the parameters, but you MUST highlight THAT specific
> element in a way that should NEVER happen otherwise.
>
> The element may be a TEdit on a tgroupbox. Now if an emergency exists and you
> start colour-flashing the tgroupbox to draw attention to the RIGHT tedit but
> a theme overrides your colour calls so it doesn't flash and the whole town is
Well, a theme bug... guess the theme author must go hide really well
now :)
And usually then it isn't a TGroupBox any more but a TAlertableFrame
that is derived from TGroupBox and has some extra style properties like
"overloaded-reactor-color" ... :)
I feel like I'm still missing your point :(
> flattened before the operator finds the right value (he cannot fix the
> problem until he knows WHAT the problem is) - well the whole theory just went
> up in smoke (as did the town).
>
> In a non computerized nuclear power station, a big LED would have flashed
> below the dial with the out of sync value, in a computerized version you HAVE
> to find a way of getting exactly the same kind of notification and theme must
> not prevent you from doing it, especially since computerising has so many
> other usefull advantages (a computer could solve simpler cases itself, like
> automatically increasing cooling if the temperature rises by a few degrees)
> in other words, a computerized interface is a good idea - but it MUST be able
> to override the theme when needed.
>
> Yes this is probably the most extreme example there is but it is a very real
> one, and just because most of us are not coding nuclear reactor controls
> doesn't mean that our reasons for occasionally having to FORCE colors or
> fonts are not good ones.
Yes, occassionaly being the keyword :)
I am in favour of bondage & discipline, so I want the case of
force-setting colors to be hard and weary and the case of installing a
normal style property to be easy :)
That is not to say that it should be impossible to set your own colors,
just really really hard. That's also why it's so hard to do in gtk+. And
it should be kept that hard to do (at least).
Of course that is all theoretical talk because when one of the supported
widgetsets of the LCL doesn't support themes, we are screwed and _have
to_ expose Color & Font directly... we'll see..
cheers,
Danny
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
