Hi,
Am Samstag, den 04.03.2006, 18:11 +0100 schrieb darekm:
> Danny Milosavljevic wrote:
>
> >Hi,
> >
> >Am Freitag, den 03.03.2006, 23:10 +0100 schrieb darekm:
> >
> >
> >>[...]
> >>If I want (as programmer) to one of buttons will be red, user should'n
> >>change it by change theme
> >>
> >>
> >
> >I merely react to this grossly out of context (so please forgive me),
> >but I just can't resist...
> >
> >Did you really mean what I read you to mean?
> >
> >Many (and I mean MANY) people can't even _see_ red (but can see colors
> >that somewhat resemble it), so they _have_ to change it... others don't
> >like the color red because of psychic problems (after witnessing
> >accidents, ...) (especially big red areas on buttons that look like a
> >puddle of blood that flows around until it reaches some obstacle).
> >Others don't like it because of other reasons.
> >Low-color displays (over modem lines etc) have 256 color limitations,
> >which makes hardcoded color values a PITA, because they eat up palette
> >entries for _all_ applications and in the end you can't read a thing.
> >(not mentioning black-and-white displays here because they got kind of
> >rare)
> >
> >http://vision.about.com/od/commonvisiondefects/ss/colorblindimage_3.htm
> >
> >Let's not go back to the dark old times where the programmer decided
> >what was good and the user needed to eat it, whether he wants to or not.
> >Also, nowadays, we usually do have some processor cycles to spare for
> >doing the right thing.
> >
> >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.
It's similar but more flexible to the borland pascal turbo vision
palette approach btw (but uses strings as ids, not integers, and is
per-class)
> >
> >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.
> >
> >
> >
>
> Yes, You have right,
> user should have possibility to change color
> but primary programmer set up all controls
> if I make button for alerts or erase (or other important or unusual
> things) I make it different
Yes, you register style properties like "alert-color" and "erase-color"
and fallback if those are not defined in the theme after all for your
class.
Having a published Color property in TControl kind of defeats that
though. Better have a list of style property names/types there.
like
TControl
StyleList
alert-color Color
erase-color Color
of course I don't know about mswin32... do they even have a mechanism
like that? I tend to think so, they added "theming" with mswinxp, right?
And qt surely has the same thing somehow...
It's really the obvious way to just abstract out style the same way html
did with css too...
>
> when user change theme they should'n make back all controls similar, he
> should change it in different way
I assume you mean there should be a class "alert control" and a class
"normal control". All alert controls surely have to look the same to
each other or else it wouldn't be ... well... alerting ...
Or, if you wish, "alertable control" which can be both depending on
internal state.
>
> When I can (but I can't) done step one, then I will do step two.
What is step 1? You can derive any kind of gtk widget from an existing
widget class, give it new properties and handle it differently in the
theme (theme value selections are per widget name and/or widget class
name and/or style property name and/or extra "detail" field internal to
the drawer - he passes that when calling the drawing functions, it can't
get much more flexible than that ;))
like,
widget_class "*Alert*" style "foo"
widget_class "*Erase*" style "bar"
or so :)
or by name:
widget "evolution_folder_frame_tree" style "green"
:)
>
>
> Darek
>
> PS. With the rest: live is not so easy as You write
Well, life is hard, especially with UNIX :)
But I am thankful to the Gnome guys that I don't have to cope with
unusable (X, motif, win32, ....) apps anymore... only a handful
crashprone apps left (filemanager, window manager, panel), Xfce
replacing them for me :)
If you mean that doing the right thing is hard, then I agree, it is,
always, everywhere :)
But it should be done.
cheers,
Danny
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
