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. 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. > 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. It's not a big problem, really. Federico _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
