Re: Treeview column width changed signal
- From: Jeffrey Barish <jeff_barish earthlink net>
- To: gtk-app-devel-list gnome org
- Subject: Re: Treeview column width changed signal
- Date: Mon, 11 Feb 2008 10:52:52 -0700
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]