Re: Treeview column width changed signal



Kristian Rietveld wrote:

If just saving the column widths of the tree view when the tree view is
destroyed is not enough, the easiest way to do this is probably to
connect to the "notify::width" signal on each column.  Remember to keep
the callback fast (do not write to files, etc) as your callback will be
called a lot, especially when the user is resizing columns with the
mouse.

The problem with your first suggestion is that I have to hook every
situation in which the tree view can be destroyed.  The obvious one is when
I change data sets.  Exiting the program is another.  There will be others
when I implement more of the program.  It certainly is possible to record
the column widths at each of these points, but it sure is clumsy.

The problem with the second suggestion is that writing a file is exactly
what I need to do.  The point of this exercise is to record in a file the
width of each column as established by the user with the mouse so that the
columns will have the same width the next time the program runs.

A signal seems the ideal solution and it's the one I used previously (in
wxWidgets), but any other suggestions are welcome.  In the meantime, I'll
work on capturing the column widths at every point where the tree view can
be destroyed.

--------------------------------

Designing around the lack of a signal keeps getting harder.  It is not
sufficient to save the column widths everytime the treeview is destroyed. 
Sometimes the column widths need to be saved when the treeview becomes
invisible (e.g., because it is on a different page of a notebook).  There
are many ways this can happen in my program.  I'm running out of fingers to
stick in the dike.

I wonder about two things.  wxWidgets provides this signal and wxWidgets
runs on GTK on some platforms.  So how can wxWidgets provide the signal if
we GTK programmers can't get it?

wxWidgets has this signal; Qt has it too.  Is there an argument for
excluding it from GTK?

When I used wxWidgets, I frequently encountered situations where I had to
design around deficiencies in the toolkit.  I believe that this is the
first time I have had to design around a deficiency in GTK.  That's pretty
good.  I'm still impressed with this toolkit even as I plead for a small
enhancement.
-- 
Jeffrey Barish




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]