Re: Distinguish column header from normal button

[Todd Berman <tberman off net>]

On Wed, 2005-09-14 at 20:55 +0300, Kalle Vahlman wrote:
> 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.
>  

2 that I know of offhand.

1) The app we are writing at work (not interesting)

2) Mozilla

Mozilla uses the same method we do to render things that look like
treeview headers. But possibly more, basically any application that
wants to render something that looks like a themed treeview header would
break.

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

No. It works. Its just a horrible hack to get working properly, which
you have to discover via reading code and testing a lot.

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

In a perfect world, yes. In reality, it seems to me to be an ABI break,
which is bad.

--Todd