Re: Deprecation of gtk_progress_bar_set_bar_style()

[Tommy McDaniel <tommstein1 yahoo com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --- Owen Taylor <otaylor redhat com> wrote:
> On Wed, 2003-03-05 at 17:42, Tommy McDaniel wrote:
> > Why not even give the application
> > developer the option? Is the 'wrong' style of
> progress
> > bar worse than a predominantly neon pink and
> glowing
> > green application, or one with any number of other
> > annoying or downright retarded properties? I'm of
> the
> > belief that, in general, the more freedom the
> > programmer has, the better. There are clearly
> worse
> > things one can do, and which GTK allows, than have
> the
> > wrong style of progress bar.
> 
> Actually, while we do have gtk_widget_modify_fg/bg,
> it's pretty hard to make *all* your widgets hot pink
> and glowing green without writing a GTK+ theme.

I'm not sure that having some default colors mixed in
with the hot pink and glowing green isn't worse.

> Generally, by giving flexibility to the application
> programmer, you are taking it away from the theme
> writer and thus desktop environment and you are
> taking 
> it away from the user.

Well, I wasn't really thinking of giving the power
solely to the programmer. The most ideal way I can
think of would be basically how I understand widget
styles to work; if the user has a theme or rc file or
something set up, then that takes precedence over what
the program says, but if there's no such thing, then
whatever the application says goes. And even if there
is a theme, if the application feels an overriding
need to override the theme for whatever reason, it can
do so. Remember that programs using GTK can look as
nontraditional as XMMS and GKrellM, neither of which I
even knew used GTK until I read it somewhere. But I'm
not saying that it should be left solely to the
programmer.

> Letting apps set things that should be theme or
> user settings just means that the users get the
> imposed preferences of each app author and get
> inconsistency, rather than getting a consistent
> set of preferences that _they_ want.

Yes, but not everyone really cares whether their
progress bars are one way or another, in which case
why not let the programmer decide if the programmer
doesn't want the default for some reason?

> I don't think we made discrete vs. continuous 
> setting a style property ... partly because we
> had to still support the deprecated function.
> But that's clearly if it is an option, it should
> be a style property, not something applications
> set.

Is that roughly what I suggested above? Thanks for
having the patience to discuss this with me, by the
way.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Z93kVB8FYP9YqDcRAnvTAJ0aGcT39nMCeMT9cZwNtT/8cbVEHwCeKv1R
NOLtSvAxO4XtRvSOSG+X/b4=
=Sh+7
-----END PGP SIGNATURE-----


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com