Re: Distinguish column header from normal button
- From: Kalle Vahlman <kalle vahlman gmail com>
- To: gtk-devel-list <gtk-devel-list gnome org>
- Subject: Re: Distinguish column header from normal button
- Date: Wed, 14 Sep 2005 20:55:23 +0300
2005/9/14, Todd Berman <tberman off net>:
> On Wed, 2005-09-14 at 12:18 +0300, Kalle Vahlman wrote:
> > 2005/9/14, Todd Berman <tberman off net>:
> > > Although, I guess if this means the hacky stuff theme authors do to see
> > > if the widget's parent is a treeview, or clist, or etree (in clearlooks
> > > case) would be removed, and then widget authors could just pass in the
> > > proper detail to the paint_box calls would end up being a win. But only
> > > once all themes support it, until then, they would have to figure out
> > > which way the theme uses to detect it needs to draw a treeview header
> > > and act accordingly.
> >
> > Are you really suggesting that implementing a good way to do things
> > should be pending on <insert good estimate of amount> hackily
> > implemented themes to be fixed (to the implementation that doesn't
> > exist) or working around those hackily implemented themes?
> >
> > Sounds like a bad suggestion to me.
> >
>
> No. But I am suggesting that breaking working applications and themes
> seems like a clear ABI break, and doesn't sound like a good thing to do.
What applications would break and why if I may ask? I thought the
rendering details were hints to the theme engines, not applications.
> I don't like the way it currently works, as it was a headache to get it
> working for myself, and assume it is somewhat of one for others as well.
>
> However, breaking the way it seems to have been working since gtk+ 2.0
> seems just as bad and as much of a headache as it being somewhat of a
> hack in the first place.
Ah, but it isn't working is it? There is no way to tell the difference
other than the hack. Besides, I'd guess that a sensible fallback chain
should be in the theme engines (eg. look at the detail, unkown falls
back to the hack, that falls back to the default rendering), and not
in treeview...
> > Good themes wwould be fixed promptly anyway (by social pressure or by
> > contributions), bad ones are not that critical ;)
> >
>
> Tell that to the users using those 'bad' themes.
And they'll tell the maintainers to upgrade for the newer GNOME they
just installed. It's not like the change would go to people's machines
and break them by themselves. If you upgrade by hand, prepare for
trouble. If you upgrade in a distro, hope that the distro makers have
prepared for trouble.
BUT
I just pretend to know anything about the way themeing works, so if
I'm wrong, please ignore me.
--
Kalle Vahlman, zuh iki fi
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]