As I observed previously, there are usually ways to design around limitations of toolkits, but sometimes they are awkward. In my case, the TreeView in question is instantiated in class A. Class A is instantiated in class B. The code that needs to know the column widths is in class D which is instantiated in class C which is instantiated in class B. There are ways to pass a "column width getter" from class A to class D, but they are awkward. Although class D needs to know the column widths, it does not currently know about the treeview in class A (and shouldn't, to minimize coupling). Another solution would be to make the column-width-getter global, which is probably what I will do even though it is also poor programming practice. I must have a file of column widths anyway so that the treeview can restore its column widths the next time the program starts. The only problem with having class D simply read the file is that it is difficult to assure that the contents of the file are updated when the column widths change. I wondered two things in my original posting: (1) How can wxWidgets provide a column-width-changed signal if GTK does not when wxWidgets runs on top of GTK? I realized that the obvious answer to this question is that wxWidgets does not use TreeViews to create lists of things. Whatever it uses must make it possible for wxWidgets to provide the column-width-changed signal. (2) Is there an argument for excluding the signal from GTK, especially considering that wxWidgets and Qt both provide it? Catching destroy/delete may serve the purpose in many cases, but it is not equivalent to a column-width-changed signal. -- Jeffrey Barish
_______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
