Lord Satan ha scritto:
On Tue, 17 Apr 2007 03:09:11 +0200
Giuliano Colla <[EMAIL PROTECTED]> wrote:
Lord Satan ha scritto:On Mon, 16 Apr 2007 23:58:30 +0200
"Graeme Geldenhuys" <[EMAIL PROTECTED]> wrote:
Forcing all GTK applications to always use the theming colors is *not*
always the developers desire.
In this case the developer has the option to use an application specific appname.gtkrc file to override the standard theme and use his own.
This is hardly a solution.
What real people in real world needs is to give the right appearence to
widgets, in order to create user friendly applications. This means dynamically
changing colors, image backgrounds, and whatever is needed to convey the right
information in the most intuitive way. For the same reasons, buttons and other
widgets are often of different size and shape, and widget style and theme goe
to hell.
Real people are indows users? And the real world is the commercial one or do you mean crappy shareware apps as they do the same?
I don't think it is very user friendly to override the users personal theme settings. The most intuitive way to convey information forces you to ignore the users theme? I think you have some problems with GUI design and how it should work.
But I won't argue with you anymore just go ahead, fix the problem and sent a patch.
You're right. If a feature isn't there, we do our best trying to provide
it. Then it's up to developers to decide if they want override user
theme or not. However, just to clarify my point of view, I've got a
couple of examples.
To test Lazarus, I've developed a small app wich mimcs Midnight
Commander. It's something anybody might want to use from time to time,
it's general purpose, and it *must* follow user personal preferences.
Colors, fonts, etc. can't be anything else but what comes from personal
theme choice. If the user loves a pink form, let him have it.
But my applications, those I get my bread and butter from, are meant for
customers which just have their specific needs, which go far beyond what
a theme can do. That's the real word I was speaking about. Such as using
a touch screen, and having buttons the size of your fingers and not the
size of your mouse pointer. Or coping with unskilled operators, which
are just confused by a "Windows like" behavior, because they're not used
to it. Jumping from one field to the next is made by arrow-up and
arrow-down, because TAB could be acceptable, but with SHIFT-TAB they get
confused. All application specific things, which do not fit in any
theme. But which make up quite a lot of the total.
So OK, lets follow a theme when it's reasonable, let's give the designer
the choice of overriding it when necessary. Delphi designers, which are
far from stupid, went that way. It's a good way and it would be a pity
to drop it. Delphi compatibility, IMHO should mean picking up the best
of Delphi, dropping the bad things.
Giuliano
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
