Re: Deprecation of gtk_progress_bar_set_bar_style()

[Owen Taylor <otaylor redhat com>]

> > 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.

Actually, modifying your widget's colors is almost
always a bad idea, but it was such a common FAQ, that
we decided we should provide a function to do it 
well, rather than having people do it in more complicated
ways and get it wrong.

> > 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. 

You can do most of this stuff with gtk_rc_parse_string()
and the RC priority system if you really need 

On rare occasions programmers *do* have legitimate reasons 
for doing things that are in the domain of the theme.
So we allow it. But there isn't a big emphasis on
making it easy.

> 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.

I'm not sure using XMMS as an example is a _positive_
argument :-). But in any case the main window of
XMMS is really only using GTK+ as an implementation 
detail.

> > 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?

Consistency, consistency, consistency. Just because
the user may not care exactly how their progressbar
looks, doesn't meant they want it to look different
in every app.

> > 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.

Not exactly ... style properties are meant for themes,
and an app programmer has to go to some lengths to
set them.

Regards,
                               Owen