Hi,
Am Samstag, den 04.03.2006, 20:00 +0200 schrieb A.J. Venter:
> > >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.
Yes, when it is too new a feature to be considered in the theming system
yet, I agree.
> 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.
Yes, but not colors. It's just getting too hairy. Since humans settled
down and have no natural enemies anymore, over time the same will happen
to us that happened to our pets: we lose color sight. Over a short or a
long period, we do. Evolution hates wasting effort on unused gadgets :)
oops, getting off-track :)
> 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.
I know and I restrain myself every day to actually use the ... stuff
that is there already instead of rewriting everything :)
> We LIKE to design interfaces and we like to be a little bit artistic
> when we do, and there is nothing wrong with that.
If it's within limits, it's ok. (Minimum) Font sizes and colors are
entirely in the user's realm though and we just can't magically set that
to a constant value for everyone. It just doesn't work :)
But if it's with layouting existing widgets and clustering them in
different windows and such, sure, all freedom there. But _for example_
creating a new-and-improved kind of "knob" control instead of a slider
is off-limits.
> Since we are the creators,
> we should be able to design something which is visually pleasing to us ?
Yes, so use style properties (and maybe propose defaults for them to
gtk) and fall back to your defaults in code if missing in theme.
I'm not saying that design shouldn't be done. Design is important. Some
stuff is outside of our realm though, like font size and color.
>
> 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.
Yes, so make a class "FooHeadline" or so that does that and defaults to
those colors and font (the actual font can even be fixed, not the size
though) and font size, but overrideable by user gtkrc config file /
theme.
> 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.
Therefore the system is extensible. You don't even have to install any
file onto the system, just call gtk_widget_install_style_property or so
and bam, _it's there_. If user puts color/font size for that name into
his theme, _it's used_.
It can be summed up with:
- Use sane defaults for font size/color
- But let user override them (and _not_ only on a per-application basis,
but at most desktop-wide and at least single-control-instance-wide)
> 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.
>
> Ciao
> A.J.
cheers,
Danny
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
