GNOME Bugzilla – Bug 402349
FileChooser's default directory is not "active"
Last modified: 2010-04-05 19:46:44 UTC
Please describe the problem: When opening a FileChooser (to select a folder), the default folder is not active, meaning it cannot be chosen. Simple workarounds: go up/down a level and navigate back to the desired folder, or if the folder is in the list of bookmarks, select it from there. Then it is active. Steps to reproduce: I've noticed this problem in Rhythmbox and Banshee (not sure of any others that choose folders off the top of my head) 1. Choose "Music > Import Folder" in Rhythmbox or "Music > Import Location, Local folder" in Banshee. 2. Immediately click "Open" to select the active folder. 3. Nothing happens. Actual results: The GTK+ FileChooser remains, the displayed directory is not chosen. Expected results: The displayed directory should be chosen. Does this happen every time? Yes, at least in these two applications. Other information:
Yep, this happens for me too. For example when choosing Extract from file-roller and selecting the destination directory: you cannot select the default without first going one up and select it from the parent.
This seems a dupe of #403985 for example...
*** Bug 403985 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > This seems a dupe of bug #403985 for example... Thanks, good catch.
I noticed this first on file-roller, if you just immediately click Extract from the "Extract" dialog, nothing happens, you have to go up a folder and then double click the folder you just left to "reselect" it which causes the extract button to become active. (just using the breadcrumbs to go back and forth didn't work for me)
*** Bug 549826 has been marked as a duplicate of this bug. ***
*** Bug 558041 has been marked as a duplicate of this bug. ***
*** Bug 560900 has been marked as a duplicate of this bug. ***
This was also reported at https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/80755 with additional information: if the "Location" text entry is hidden, then the bug does not occur. I am still observing this in Ubuntu 8.10, meaning it also applies to GTK+ 2.14.4 and possibly later versions: $ lsb_release -rd && apt-cache policy libgtk2.0-0 Description: Ubuntu 8.10 Release: 8.10 libgtk2.0-0: Installed: 2.14.4-0ubuntu1 Candidate: 2.14.4-0ubuntu1 Version table: *** 2.14.4-0ubuntu1 0 500 http://ubuntu.mirror.rafal.ca intrepid/main Packages 100 /var/lib/dpkg/status
Still present in 2.16 I tried to use a gtkfilechooser for the first time after being warned about the original pathselection being deprecated in my app. Sigh.
I was able to sort out my problems with the entry widgets in the GtkFileChooser dialog. I think when entry widgets have focus an extra signal is sent which causes issues. If the location bar has focus case as mentioned here, I was getting a "file exists" warning dialog after hitting the OK button. If I changed the action of the dialog to "save as" so that the filename entry widget was shown, then my handler was called twice when this entry had focus and I clicked the Ok button. Both issues were resolved by manually removing the response IDs from the glade file that glade-2 added automatically.
Created attachment 142315 [details] [review] Check file list for a selection if location_entry is empty I've written a patch (against the current git HEAD) to fix this. The fix basically reverts to checking if anything in the file list is selected in case the location_entry is empty. Can someone review/test this to see if it causes any other problems?
Ok, I just realized that the real scenario for which I wrote this patch is this: 1. Backup (if desired) and remove $HOME/.config/gtk-2.0/gtkfilechooser 2. mkdir /tmp/gtk 3. cd /tmp/gtk 4. mkdir foo 5. gedit 6. in gedit, hit CTRL-O to open a file 7. note that foo is selected by default and hit ENTER to cd to it and then cancel 9. hit CTRL-O again to open a file 10. hit CTRL-L to open the Location field 11. hit ENTER and nothing happens But the patch fixes this issue too. In essence I guess the underlying bug for both issues is the same -- if the location bar is open and empty, nothing gets done.
*** Bug 607066 has been marked as a duplicate of this bug. ***
*** Bug 527654 has been marked as a duplicate of this bug. ***
Is anyone working on getting the patch submitted? As the number of duplicates shows, this bug is an annoyance for lots of apps.
Created attachment 156306 [details] [review] Different approach I fixed this following a different approach (sorry, didn't notice there was a patch before). I'll try to poke a maintainer to choose the best patch to be committed.
Bug 557689 may be a duplicate of this (maybe not, so I talked about it in bug 557689 comment 14).
Bug 557689 is definitely a dupe. Patch in bug 557689 comment 13 looks like the patch in bug 402349 comment 12 along with making sure that nothing is selected in case the chooser is a GTK_FILE_CHOOSER_ACTION_SAVE. Borrowing from Andres' patch in bug 402349 and this one in bug 557689 comment 13, I guess the right way for this would be to goto file_list if impl->action is neither GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER nor OPERATION_MODE_BROWSE. In all other cases, it should return a FALSE. That ought to take care of CREATE_FOLDER as well, mentioned in bug 557689 comment 15. In fact, I guess Andres' patch would provide the same effect as all of the above and is hence probably more complete. I haven't tested it; this just a visual review.
(In reply to comment #19) > <snip/> Thanks for your insights. Anyway, anyhow, the patch in bug 557689 was reviewed, and applied by Cody, and it fixed this one as well (as a side effect or because they are indeed dupes... whatever!). Excerpt from IRC (#gtk+): <knocte> bratsche: meh, given that I cannot update my gtk+ right now, would you mind testing with your patch applied? easiest use case is this described for banshee: https://bugzilla.gnome.org/show_bug.cgi?id=549826 <bratsche> knocte: Yeah I've already tested it in Banshee. <knocte> bratsche: the select_folder mode? to import a directory? <knocte> what happened? <bratsche> It just starts importing the music. <knocte> so it's fixed? <bratsche> Yeah.