Re: Distinguish column header from normal button

[Todd Berman <tberman off net>]

On Wed, 2005-09-14 at 13:16 -0500, Federico Mena Quintero wrote:
> On Wed, 2005-09-14 at 02:01 -0700, Todd Berman wrote:
> 
> > The current hacks that 3rd party developers have to go through when they
> > want to render something that looks like a themed native treeview header
> > are bad enough (creating a fake treeview, adding a column, and passing a
> > widget somewhat deep in the columns child tree). Making it completely
> > private will prevent this from being possible at all.
> 
> Generally, if you want to do "make a widget of type Foo look like a
> widget of type Bar", you are on your own.  GTK+ doesn't have explicit
> support for that.
> 

Yeah, but the real world has requirements :).

> If you are writing your own list widget *and* you want it to look like
> the stock GtkTreeView, I'd say it's way easier to just set your button
> headers to use the detail hint I proposed, than hacking up a treeview
> and extracting stuff from it.

Oh for sure, it is easier, but it is a break, because old themes wont
support it, and new themes will, and 3rd party apps and ISVs will be
left in the cold again.

> 
> > 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.
> 
> If current themes check the parents of buttons to make treeviews a
> special case, they'll keep working even with the proposed detail hint.
> New themes can first check the detail hint, then fall back to checking
> the parent of the button in case an older GTK+ is installed.
> 

They all seem to do a check to see if the detail is "button" and if the
widget->parent is treeview or clist.

This is the issue. If the details gets changed to "treeview-header-left"
then that check stops matching for older themes, and then they stop
working.

I would love to see the "treeview-header-left" stuff personally, but
breaking all themes and apps attempting to use the current system sucks
bad too :(.

While I understand that none of this is really documented, and could (I
guess) fall under some peoples interpretation of not breaking ABI, to
me, it really would seem to be one.

--Todd