Jeffrey Barish wrote: > 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.
When you drive a motorcycle, you shift gears by flipping a little toe pedal up and down with your left foot. When you drive a car, you shift gears with the stick shift. If you've been driving a motorcycle for 10 years and then drive a car, it's not correct to say that the car has a bug because it has a stick shift when it should have a toe thingie. It's a different way of doing things - no more, no less. You probably could come up with some Rube Goldberg way of shifting gears in a car with your toe, but that wouldn't make it the right, or best, way to do it ..... it'll be fragile, overly complicated, and will make life very difficult for you if you ever need to have it repaired. As far as coupling/decoupling is concerned ... much of that id dependant on the structure of your application and the tightness of the data. If your application calls for coupling, then couple, and don't beat your head against a wall trying to pretend it doesn't exist - or restructure. That being said ..... Check my first post to you - it contains ALL the code you need, period. I deal with exactly the same problem you have, for exactly the same reasons you have to. > Catching destroy/delete may serve the purpose in many cases, > but it is not equivalent to a column-width-changed signal. Stop trying to implement a toe pedal, and just use the stick shift. _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
