GNOME Bugzilla – Bug 132043
gnome file entry should use the GtkFileChooser API
Last modified: 2004-12-22 21:47:04 UTC
As far as I can see in a gnome 2.5.x built a few days ago with jhbuild, the GnomeFileEntry widgets still use the GtkFileSelection API, I'll try to have a look at the code and provide a patch that uses GtkFileChooser, but cannot guarantee this in a short term :(
Created attachment 23707 [details] [review] yay! patch for fixing this
Set prio --> High due to PATCH set sev --> major due to big UI inconsistence without it Anders, this patch looks okey for me. Can you review it?
Wow, this is an API change! This changes at GnomeFileEntry GtkWidget *fsw; to GtkWidget *fc; and this is in the public part. Possible solutions? A GnomeFileEntry using the old fileselection dialog is really UI-ugly, but it's too late for marking it as deprecated and adding a new one...
gosh, that's true :/, and every solution I can find is crappy... there is a GtkWidget (the name is the less important issue here), and it's now casted to a GtkFileChooserDialog, so breaking the programs that access this widget directly is unavoidable (at least we'd break their behaviour) I guess that we should wait for 2.8 or bribe the release team...
Carlos, can you ask about this on d-d-l?
*** Bug 132907 has been marked as a duplicate of this bug. ***
Created attachment 24214 [details] [review] patch that fixes this without breaking API backwards compatibility
the patch adds a "use_filechooser" property to gnome-file-entry and gnome-pixmap-entry (which inherits from the former), it defaults to FALSE, and if set to TRUE, then uses the GtkFileChooser API The gnome-icon-entry only uses the GtkFileSelection stuff internally, so it could be safely switched to GtkFileChooser without external changes ok to commit?
Looks good, but could you make the property a construct only property?
Making this prop construct only woudn't allow libglade to set it, and lot of programs are using GnomeFileEntry via libglade. I'm attaching a patch to register this new property with glade. I'm also attaching the glade-2 patch with allows to edit this prop if you can test if.
Created attachment 24226 [details] [review] Patch for libgnomeui to register this prop with glade
Created attachment 24227 [details] [review] Patch for glade-2 supporting this prop
Ok, The patch is committed, I guess the bug will be closed when Fernando commits his patches :)
Committed. Closing!
Apparently, we are not handling gnome_file_entry_set_directory_entry (entry, TRUE) correctly. In gnome-search-tool, I use this widget for the 'look in files' entry, and I set the values of use_filechooser and directory_entry properties to TRUE. But, the filechooser displays files and folder. The following error is sent to stderr... (gnome-search-tool:23954): GLib-GObject-WARNING **: value "TRUE" of type `gboolean' is invalid or out of range for property `folder-mode' of type `gboolean'
Created attachment 24337 [details] [review] Proposed patch file to fix the folder-mode problem described above.
Brbrbr, same fix here at just same time!!!! I spent 40 minutes or more with the ugly gdb crashing before realizing that "-1" vales! BTW, in gsearchtool.c... is it not better: g_object_set (G_OBJECT (interface.look_in_folder_entry), use_filechooser", TRUE, NULL); than: { GValue value = { 0 }; g_value_init (&value, G_TYPE_INT); g_value_set_int (&value, 1); g_object_set_property (G_OBJECT (interface.look_in_folder_entry), "use_filechooser", &value); } I'not sure if this leaks, but really looks worse :)
g_object_set (G_OBJECT (interface.look_in_folder_entry), use_filechooser", TRUE, NULL); Yah. Actually, I have this exact same code in my local version of gnome-search-tool. I'll check it in after when the libgnomeui issue is fixed. ;-)
So, can I commit?
Hmm, I wonder if we shouldn't try to fix this directly in gtk, it makes more sense. ccing federico
any new about this?
committed.