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

Some programs just don't fit the default mold. Add
Mozilla to that list of programs that use GTK yet
don't look at all like it, as should be their right.
Why should they have to buy into some big GTK
look-and-feel scheme just because that's the graphical
toolkit that they choose to use? Using a graphical
library doesn't mean you want to look like every other
program that has ever used that library, nor should
you be coerced to.

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

I'd hope so, since I think it was the RC priority
system that I was remembering and trying to descibe.

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

Does that mean that there's still a way to change the
progress bar style besides the deprecated function?

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

Perhaps not (I personally wouldn't care, but that's
me), but if it got to be annoying they could set it to
be their preferred way in an RC file in the scheme I
mentioned. And if they don't care then the developer
gets to choose what his application looks like, not a
GTK developer. But the argument of 'consistency' can
be applied to everything that makes GTK flexible as a
reason to eliminate the flexibility. Things start
becoming real consistent when you don't have choices.
Consistency is the reason we have defaults, but I
don't think that means that we should eliminate the
possibility of deviating from those defaults if the
developer has a conscious reason to do so. Who are we
to judge whether the reason is good or bad?

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

I'm not an expert, but is it as easy as calling
something like gtk_rc_parse_string() and/or company?

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

iD8DBQE+atiNVB8FYP9YqDcRAtUMAJ0fgtwqWu6y0Dhyme8G+MP7EkDUYgCfblTz
V+xBMXDCwNu38zLnfvb7nbI=
=nLge
-----END PGP SIGNATURE-----


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