On Wed, 2005-09-14 at 12:18 +0300, Kalle Vahlman wrote: > 2005/9/14, Todd Berman <[EMAIL PROTECTED]>: > > 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. 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. > 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. --Todd _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list