GNOME Bugzilla – Bug 436576
GtkFileChooserButton title from supplied dialog
Last modified: 2007-09-11 18:57:11 UTC
I've been asked to present the issue here, so here's the mail: "Hello! I've fought a few hours with the working of GTKFileChooserButton. I wanted to have a menu item and the button in toolbar opening the same GTKFileChooserDialog. To make this happen I've constructed the GTKFileChooserButton using the constructor, that allows passing my custom GTKFIleChooserDialog. The problem is, that the dialog HAS TO have a button with RESPONSE_ACCEPT, otherwise the button won't set it's label and icon accordingly after selecting a file. I had my 'Open' button in the dialog use RESPONSE_OK and it displayed only the icon, the label was empty. The second issue is with the title. Even when supplying my own FileChooserDialog with the title set to something custom, FileChooserButton resets the dialogs title to default. So first I propose to make some note in the documentation (and maybe in the FAQ), that the supplied dialog needs to have RESPONSE_ACCEPT as the positive result. The second thing is to stop GTKFileChooserButton from changing the title in the supplied dialog. Best regards Cz@rny" I've put some test program to show the problem. I'm no GTK programmer (at least not in plain C), but here it is: ftp://ep09.pld-linux.org/people/czarny/gtk/filechooser-test.tar.bz2 Here's a patch I've put together. It built with gtk+-2.10.12 and corrects both the API and the documentation.: Index: gtkfilechooserbutton.c =================================================================== --- gtkfilechooserbutton.c (wersja 17800) +++ gtkfilechooserbutton.c (kopia robocza) @@ -2795,6 +2795,10 @@ * file-picking window. Note that @dialog must be a #GtkDialog (or * subclass) which implements the #GtkFileChooser interface and must * not have %GTK_DIALOG_DESTROY_WITH_PARENT set. + * + * Note also, that the dialog needs to have it's accept button set + * with response %GTK_RESPONSE_ACCEPT in order for the button to + * dispaly the loaded file's icon and name in it's label. * * Returns: a new button widget. * @@ -2805,9 +2809,19 @@ { g_return_val_if_fail (GTK_IS_FILE_CHOOSER (dialog) && GTK_IS_DIALOG (dialog), NULL); - return g_object_new (GTK_TYPE_FILE_CHOOSER_BUTTON, + gchar *dialog_title; + g_object_get(GTK_WINDOW (dialog), + "title", &dialog_title, + NULL); + + GtkWidget *button = g_object_new (GTK_TYPE_FILE_CHOOSER_BUTTON, "dialog", dialog, + "title", dialog_title, NULL); + + g_free(dialog_title); + + return button; } /** Hope it helps Cz@rny
What's wrong?? I've been asked to submit the bug on gnome-devel list, I've provided a test program to illustrate it, I've given a patch - why now answer??
Nothing is wrong, but there are 2000 open bugs in the GTK+ bug database. Please be patient.
It is somewhat unfortunate to have a single bug report for two issues. I can confirm the issue with the dialog title. This is what we do in GIMP to work around this issue: /* work around bug in GtkFileChooserButton */ title = g_strdup (gtk_window_get_title (GTK_WINDOW (dialog))); button = gtk_file_chooser_button_new_with_dialog (dialog); if (title) { gtk_file_chooser_button_set_title (GTK_FILE_CHOOSER_BUTTON (button), title); g_free (title); } The patch is however not suited to fix this issue properly. The new() method should not include any additional code or the behavior will be different if the GtkFileChooserButton is instantiated using gtk_file_chooser_button_new_with_dialog() or by using g_object_new().
Created attachment 93418 [details] [review] patch against gtk-2-10 that fixes the dialog title problem
Created attachment 93419 [details] [review] same patch with improved comments
Created attachment 93750 [details] [review] Patch solving the issue differently. Actually it seems the has_title boolean is only good for making this patch work. In the unpatched file the boolean has no effect since the TITLE property is always set *after* GObject::constructor(). Attached patch gets rid of the has_title boolean and fixes the bug differently.
(In reply to comment #6) > Created an attachment (id=93750) [edit] > Patch solving the issue differently. > > Actually it seems the has_title boolean is only good for making > this patch work. In the unpatched file the boolean has no effect > since the TITLE property is always set *after* GObject::constructor(). > > Attached patch gets rid of the has_title boolean and fixes the > bug differently. > the change looks good to me, though i really don't know that code. i'd suggest you wait a week before applying this to see if Matthias or James (who last hacked on the file) have anymore comments, adding James to CC:...
Oh -- it's been 3 months -- I've forgotten bout the matter. Yea -- the boolean was strange and setting the title each and every time seems a good idea. I'm no gtk internals hacker, so please fix it in a matter suitable for You. Please also apply the notice patch fragmet bout the need of having RESPONSE_ACCEPT in order to work properly. In which version will the change be done?
Yes please update the docs for gtk_file_chooser_button_new_with_dialog, I took me quite a while to figure out what was wrong with my code (GTK_RESPONSE_OK vs. GTK_RESPONSE_ACCEPT)
Created attachment 94630 [details] [review] Updated patch I agree and have updated the patch. Changes in the new patch: - Accept GTK_RESPONSE_ACCEPT *and* GTK_RESPONSE_OK for confirming files. - Document that fact with gtk_file_chooser_button_new_with_dialog(). - Fix all compiler warnings in the file.
Fixed in SVN: 2007-09-11 Michael Natterer <mitch@imendio.com> * gtk/gtkfilechooserbutton.c: remove useless member "has_title" from the private struct and simply set the default title in constructor() whenever we create a dialog or the supplied one has no title. Also accept RESPONSE_ACCEPT *and* RESPONSE_OK as affirmative responses and document that accordingly. Fixes bug #436576. Fixed all compiler warnings in the file.