Treeview column width changed signal
Is there a way to be notified when the width of a column in a treeview changes? I would like to record the new column widths so that I can set them to the same values the next time the window opens. The only signal in TreeViewColumn is clicked, which doesn't seem to do what I need. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
On Tue, Sep 25, 2007 at 05:45:51PM -0600, Jeffrey Barish wrote: > Is there a way to be notified when the width of a column in a treeview > changes? I would like to record the new column widths so that I can set > them to the same values the next time the window opens. The only signal in > TreeViewColumn is clicked, which doesn't seem to do what I need. 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. regards, -kris. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
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. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
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 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
Jeffrey Barish wrote:
> Kristian Rietveld wrote:
>
> 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.
>
I do this exact thing in an application I'm developing now. But I only
do it in one place - a callback routine that is called for both the
delete and destroy events.
> 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.
>
Again, I do the same - in my case, entries in an sqlite database. Some
routines are left out, but what I have included should give you the idea.
You don't hide/delete a window often at all (well - certainly not
"often" as far as the computer is concerned), and the time required
isn't noticeable - period.
Hope this helps?
First, setting the handlers:
SetSignalHandler(GTK_WIDGET(GetSWWindow()),"delete-event",
G_CALLBACK(HideSongWindow));
SetSignalHandler(GTK_WIDGET(GetSWWindow()), "destroy-event",
G_CALLBACK(HideSongWindow));
ANd then:
static void HideSongWindow(void)
{
SWSaveWindowPos();
SWSetVisible(FALSE);
}
void SWSaveWindowPos(void)
{
GList *cols;
intindex = 0;
privateOpenDatabase();
avSaveWindowGeometry(GetSWWindow(),NULL, NULL);
/*
** save the order and size data for the different columns
*/
cols = gtk_tree_view_get_columns(GetSWTreeView());
g_list_foreach(cols, (GFunc) SWSaveColumnData, (gpointer) &index);
g_list_free(cols);
privateCloseDatabase();
}
static void SWSaveColumnData(GtkTreeViewColumn *column, int *index)
{
char name[32],
value[64];
intwidth;
if (*index)
{
g_object_get(G_OBJECT(column), "width", &width, NULL);
sprintf(name,"SongWindowListColumn%02d", *index);
sprintf(value,"%d %d %d %s",
gtk_tree_view_column_get_sort_column_id(column),
gtk_tree_view_column_get_visible(column),
width,
gtk_tree_view_column_get_title(column));
avStoreConfData(name, value);
}
(*index)++;
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
Gorshkov wrote: > I do this exact thing in an application I'm developing now. But I only > do it in one place - a callback routine that is called for both the > delete and destroy events. Thank you for your suggestions. I don't get a delete, destroy, or even a hide signal when the treeview disappears because I switched to a different page of a notebook. I could, of course, detect when I change pages of the notebook, but then I am off plugging holes in the dike. The problem is that there are ways to get to portions of my code that read the column-width file in which the treeview has not been destroyed, so the column-width file has not been updated. I suppose that this code will have to extract column widths from the treeview rather than read them from the file, but then remote portions of the code will need to be coupled to this treeview. The file was a neat way to decouple the code because I need to store the widths anyway. There is always a way to get around a limitation of a library, but I still wonder why the GTK developers are comfortable with this limitation when other GUI toolkits provide the appropriate 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
Re: Treeview column width changed signal
Jeffrey Barish wrote: > Gorshkov wrote: > >> I do this exact thing in an application I'm developing now. But I only >> do it in one place - a callback routine that is called for both the >> delete and destroy events. > > Thank you for your suggestions. > > I don't get a delete, destroy, or even a hide signal when the treeview > disappears because I switched to a different page of a notebook. I could, > of course, detect when I change pages of the notebook, but then I am off > plugging holes in the dike. The problem is that there are ways to get to > portions of my code that read the column-width file in which the treeview > has not been destroyed, so the column-width file has not been updated. I > suppose that this code will have to extract column widths from the treeview > rather than read them from the file, but then remote portions of the code > will need to be coupled to this treeview. The file was a neat way to > decouple the code because I need to store the widths anyway. There is > always a way to get around a limitation of a library, but I still wonder > why the GTK developers are comfortable with this limitation when other GUI > toolkits provide the appropriate signal. You don't have to set the widths again every time you show them. When the TreeView becomes hidden/not hidden or visible/not visible, it will have the same properties and values it had the last time it was visible. The ONLY time you have set those values is when you display/realize the TreeView for the first time - I do it in my initialization code when I first create the widget. It's not a limitation in the library, because it's not a requirement - you're just thinking that you have to do something when you don't, because you had to do it that way in the other toolkits you've used. 2 of the 7 TreeViews in my application are also in tabs. And I can assure you that using a callback for those two signals, as I have, will handle every case you could possibly run into. Please note the call to SWSaveWindowGeometry() in SWSaveWindowPos() - because I also use these routines, and variants of them, to save the windows size and location on the screen so that they can be restored on startup as well. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
Gorshkov wrote: > You don't have to set the widths again every time you show them. When > the TreeView becomes hidden/not hidden or visible/not visible, it will > have the same properties and values it had the last time it was visible. > The ONLY time you have set those values is when you display/realize the > TreeView for the first time - I do it in my initialization code when I > first create the widget. I know this. I am not sure what I wrote that gave you the impression that this is what I am trying to do. I will try again. A portion of my code that is not directly related to the treeview in question nevertheless has to know what the column widths are in the treeview. Currently, it tries to obtain this information by reading a file that is written by the treeview whenever it is destroyed. Unfortunately, the treeview generally has not been destroyed when I get to this portion of code, so the file has not been updated. Therefore, the column widths that this portion of code reads may be obsolete. I think you may have assumed that the portions of my code that need to know the column widths use that information to set the column widths. In fact, these portions are performing functions unrelated to the treeview. The only time the treeview uses the information in the file is on program start when the treeview is first realized. To preserve the decoupling afforded by the file, I have to write the file whenever I leave the mode in which the treeview is visible. However, there are several ways in which it is possible to leave this mode. Whenever modifications to the program create additional ways, I need to remember to add code to write the file. This expanding requirement is what I meant by sticking fingers in holes in the dike. If I jettison the decoupling afforded by the file, then I could have the code that needs to know the column widths either cause the file to be written before it reads the file or simply extract the column widths from the treeview. Either way, I have coupled disparate sections of code that should not be coupled. I also need to store the column widths in a file so that the treeview will have the same column widths the next time I run the program. Capturing the column widths when I destroy the treeview works fine for this requirement, although it would be more elegant to write the file only when the column widths actually change. Sorry that I am not communicating better. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
Jeffrey Barish wrote: > Gorshkov wrote: > >> You don't have to set the widths again every time you show them. When >> the TreeView becomes hidden/not hidden or visible/not visible, it will >> have the same properties and values it had the last time it was visible. >> The ONLY time you have set those values is when you display/realize the >> TreeView for the first time - I do it in my initialization code when I >> first create the widget. > > I know this. I am not sure what I wrote that gave you the impression that > this is what I am trying to do. I will try again. A portion of my code > that is not directly related to the treeview in question nevertheless has > to know what the column widths are in the treeview. Currently, it tries to > obtain this information by reading a file that is written by the treeview > whenever it is destroyed. Unfortunately, the treeview generally has not > been destroyed when I get to this portion of code, so the file has not been > updated. Therefore, the column widths that this portion of code reads may > be obsolete. I think you may have assumed that the portions of my code > that need to know the column widths use that information to set the column > widths. In fact, these portions are performing functions unrelated to the > treeview. The only time the treeview uses the information in the file is > on program start when the treeview is first realized. > > To preserve the decoupling afforded by the file, I have to write the file > whenever I leave the mode in which the treeview is visible. However, there > are several ways in which it is possible to leave this mode. Whenever > modifications to the program create additional ways, I need to remember to > add code to write the file. This expanding requirement is what I meant by > sticking fingers in holes in the dike. > > If I jettison the decoupling afforded by the file, then I could have the > code that needs to know the column widths either cause the file to be > written before it reads the file or simply extract the column widths from > the treeview. Either way, I have coupled disparate sections of code that > should not be coupled. > But you're not actually decoupling anything - you're just adding a layer of indirection to it. I assume you already have a routine that is reading the information from the file once it's already been generated. Add some checks to the top of that routine - if the tree is newly created and not intialised, read the file ... but cache the information. If the the TreeView exists and HAS been initialized, you can use excerpts from my code to get the current column widths and return it to the caller. That way you only need to read the file once - the first time the TreeView is made visible - and other times grab current data, which will certainly be orders of magnitude faster than re-reading from a file. With this approach, the only time you DO have to update the file is when you destroy the window, and/or exit your application. > I also need to store the column widths in a file so that the treeview will > have the same column widths the next time I run the program. Capturing the > column widths when I destroy the treeview works fine for this requirement, > although it would be more elegant to write the file only when the column > widths actually change. > > Sorry that I am not communicating better. My bad. I've gotta stop posting before my first pot of coffee :-) Hope this answer is a little more helpful? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
On Feb 11, 2008 1:35 PM, Gorshkov <[EMAIL PROTECTED]> wrote: > 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. > > Stop trying to implement a toe pedal, and just use the stick shift. I'm not sure why your tone is overly aggressive. I have to admit that I've been following this discussion with interest because I, too, have wanted a treeview column width signal for my application. Using the "stick shift", as you suggested, is overly complicated and a reinvention of the wheel for each application developer. I have the code working correctly now for my application, but it's not nearly as trivial as it should have been. There's nothing wrong with constructive criticism of the graphical toolkit, especially if it can lead to an easier framework with which to work. After all, shouldn't that be the ultimate goal? For what it's worth, I too would love to see such a signal. Scott ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
Scott Horowitz wrote: > On Feb 11, 2008 1:35 PM, Gorshkov <[EMAIL PROTECTED]> wrote: >> 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. >> >> Stop trying to implement a toe pedal, and just use the stick shift. > > I'm not sure why your tone is overly aggressive. I have to admit that > I've been following this discussion with interest because I, too, have > wanted a treeview column width signal for my application. Using the > "stick shift", as you suggested, is overly complicated and a > reinvention of the wheel for each application developer. > Lack of patience, and the feeling that I was talking to a brick wall, to be perfectly honest. I even posted all the code he needed to implement the solution - and given that it was only about 20 or 30 lines total, I wouldn't exactly call it overly complicated. The only code I did not give him was the code to actually save the data to a file - everything else - the signal handlers, callbacks, etc, is there. > I have the code working correctly now for my application, but it's not > nearly as trivial as it should have been. I will agree with you if you say that FINDING the solution to the problem isn't trivial - it's not always easy to find what you want in the documentation, and unless you happen to stumble across an exact example somewhere on the web, it can take you months to figure out how to do something that is quite simple - once you know how. It took me almost 2 months to stumble across the info I needed to implement my solution to the problem, so I am VERY sympathetic. > There's nothing wrong with > constructive criticism of the graphical toolkit, especially if it can > lead to an easier framework with which to work. After all, shouldn't > that be the ultimate goal? > Absolutly - and I have no objection to constructive criticism. My issue is that I didn't find the criticism constructive. He had done things in a certain way in other toolkits, and wanted to be able to do it the same way in THIS toolkit - the fact that he had the solution laid down right in front of him didn't seem to matter. It wasn't the way he was used to, so it was wrong. that is where the toe thingie/stick shift came from > For what it's worth, I too would love to see such a signal. > When I started this application, I would (and did) agree with you - I tore my hair out trying to figure out a solution. But now that I have it, I disagree. I think the solution is easy, it's straight-forward, and simple to implement - it's just not the way *I* would have thought of it, either ... which is why it was so difficult to discover. > Scott > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
Jeffrey Barish wrote: > Gorshkov wrote: > >> You don't have to set the widths again every time you show them. When >> the TreeView becomes hidden/not hidden or visible/not visible, it will >> have the same properties and values it had the last time it was visible. >> The ONLY time you have set those values is when you display/realize the >> TreeView for the first time - I do it in my initialization code when I >> first create the widget. > > I know this. I am not sure what I wrote that gave you the impression that > this is what I am trying to do. I just reread the thread and what you wrote to give that impression is quite clear to me. I suggest you do the same to review what you said and to re-evaluate what people have suggested. I'll offer one further suggestion: In order to determine the column widths, first see if the treeview exists and if it does, ask it. If it doesn't exist, read the widths from a file. Create and maintain the file by hooking the destroy and delete events as Gorshkov suggested. Cheers, Dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
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
Re: Treeview column width changed signal
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
Re: Treeview column width changed signal
Gorshkov wrote: > Lack of patience, and the feeling that I was talking to a brick wall, to > be perfectly honest. I even posted all the code he needed to implement > the solution - and given that it was only about 20 or 30 lines total, I > wouldn't exactly call it overly complicated. The only code I did not > give him was the code to actually save the data to a file - everything > else - the signal handlers, callbacks, etc, is there. I had already implemented the solution you gave me before I resurrected the old thread. It works for restoring the column widths after exiting and restarting the program. My lengthy comments were not criticism of your suggestion but an attempt to explain why its application does not meet all of my needs in a straightforward manner. The remaining problem is that a remote section of code needs to know the column widths while the program is running. It would have been trivial to obtain the information from the file, but the file does not get updated when the column widths change, only when the treeview is destroyed. The solution which you, Dave Howorth, and even I have suggested in this thread is to read the column widths from the treeview. Usually, implementing that solution is also trivial. It is not trivial in my situation because the remote section of code does not know about the treeview. Nevertheless, the solution is practicable. Note that in my original posting I did not ask for a solution, I asked why GTK has this small limitation. I understand that there is a way to implement a solution, but I long for the solution that would have been trivial. The implication that writing the file when the treeview is destroyed is equivalent to writing it when the column widths change is wrong. Although there are cases where the two approaches are equivalent, they are not equivalent in situations that Scott and I have encountered. Moreover, the designers of Qt and wxWidgets evidently don't consider the two approaches to be equivalent because they chose to support both. My objective in posting my message was simply to encourage the designers of GTK also to support both. With that resolution, you would be free to continue to use the destroy signal and I would be free to use the column-width-changed signal, even if we were both doing so out of stubborn adherence to the familiar. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
With some trepidation about extending this wearisome thread, I thought that I would post for the benefit of the record some information about a solution that I found. It is based on a suggestion made by Kristian Rietveld in the previous incarnation of this thread (which I quoted when I resurrected the thread). He suggested connecting to the "notify::width" signal on each column. He warned that I needed to keep the callback fast and specifically directed that I not write a file in the callback. As writing a file was the purpose for detecting that column width had changed, it did not seem as if his suggestion would work. However, what does work is to use notify::width to set a flag indicating that the file needs to be written. Then catch the button-release event for the treeview that contains the columns. If the flag is set when I get button release, then I write the file (and clear the flag). This solution works almost perfectly, but I do get a spurious write when I first select a row. I hope that someone will be able to glean something useful from this thread so that it can now rest in peace. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
