> >gtk does the right thing by letting the programmer register "style
> >properties" for a widget class. These names can then be used in themes
> >and gtk will assign the theme color to the style property of the widgets
> >of that class on runtime.
> >
> >I know that it usually depends on the target audience whether it's ok to
> >take shortcuts like hardcoding colors (if your program is to be used by
> >an internal group of 5 people, new people never enter, and none of them
> >has color blindness, sure, hardcode red all you like). _But_ when
> >designing a framework, that is the wrong way to take because they affect
> >all the users there are.
>
What you are saying is correct, but not absolutely so. There are exceptions to
every rule and the fact is programmers MUST have the capacity to sometimes
enforce certain look and feel changes regardless of themes because themes are
always generic (they are meant to apply to all apps) and sometimes a program
is doing something which is simply specific to that program and the
programmer needs a way of visually explaining a concept to users which simply
does not exist in any theming system.
Take tappytux for example (the program which was the reason why I started the
gtk2 font setting patches). Number one requested feature from users was: make
the text entry bar at the bottom HUGE.
This was not MY choice, it was THEIR choice. This was not something that could
be done for EVERY tedit in the program, but it HAD to be done for THAT tedit
- because the nature of the program was such that, that "entry bar" had to be
really big and accentuated.
Why ? Because the program is for children, and it's a game - and people who
only learned to read a month ago needs to be able to read what they type in
there at a single glance.
The rest of the program they have TIME to spell out letters, if they have to
do it there they will never learn not to have to (at least not from the
program which is supposed to have been written to help teach them this)
because they will simply go game over before they finish the first word.
See what I am getting at ? It's partially intended audience but it's also
purpose of the program, sometimes a programmer needs to be able to enforce
some things in the look and feel department.
Finally there is the simple reality that despite the lack of credit popular
culture gives us in this regard nearly all programmers are highly creative
people. We LIKE to design interfaces and we like to be a little bit artistic
when we do, and there is nothing wrong with that. Since we are the creators,
we should be able to design something which is visually pleasing to us ?
I am not saying we should force users to use bright-red buttons (and I know
that green-red as distinguishing features is a horrible thing to do to users
since about 8% of men cannot distinguish them), but I am saying that we
SHOULD be able to sometimes say "This is the main headline part of my main
screen - I would really like it if it was in Mincho Gothic font in blue
letters on a cream colored button -because it is not SUPPOSED to be the same
as the other buttons" - and that I believe is entirely a good thing, and
something I encourage in my trainee's.
Programmer designs should never detract from usability, but we should still be
able to employ a little bit of creativity in interface design - the job of
interface design is to take an abstract computing concept of some sort and
create a visual analogy that allows non-computer experts to understand what
they program does for them and how to achieve their goals with it. This IS a
creative process and ingenuity can make all the difference here, especially
with custom apps which are often the first to design for a certain concept.
To imagine that any theme can be broad enough to handle ALL the problems any
program will ever be asked to solve and still be usable as a theme is
downright ridiculous.
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.
Ciao
A.J.
--
"there's nothing as inspirational for a hacker as a cat obscuring a bug
by sitting in front of the monitor" - Boudewijn Rempt
A.J. Venter
Chief Software Architect
OpenLab International
www.getopenlab.com
www.silentcoder.co.za
+27 82 726 5103
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
