From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.1 (X11; Linux i686; U;) Gecko/20020420 Description of problem: Unless I click in the 'add all files in directory' the audio tracks dont appears in the xmms file chooser. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. xmms & 2. insert an audio cd in the cdrom drive ; eject -t. 3. In the playlist click on add file and go into /mnt/cdrom. Actual Results: No file appears. If I click on the 'add all files in directory' button then the directory content appears in the file chooser but nothing is added to the playlist. As the content appeared, if i click again on the 'add all files' button the tracks are added. Expected Results: I should see the tracks immediatly.. Additional info: When the tracks have appeared in the file chooser if I click on the '.' directory on the left side all tracks disappear again. Same result if I change the directory and go back in /mnt/cdrom.
A friend of mine have the same problem. So I think this is a problem not just for me... BTW, If the file chooser opens directly in /mnt/cdrom, tracks are present but disappears again if change the directory and go back to /mnt/cdrom.
I'm not sure, but you may need to "mount /mnt/cdrom". cdrom doesn't get mounted just by insertion, thus remaining invisible. Check this by "cd /mnt/cdrom; ls". See, if mount helps.
You're very wrong. Audio CD cannot be mounted.
Why do you go into /mnt/cdrom when it is an Audio CD?
*sigh* Because Xmms audio-cd-plugin is configured to display audio cd tracks in /mnt/cdrom. If you dont believe me then in your xmms press C-p (preferences) click on the audio cd input plugins and then press the configure button to see that /mnt/cdrom is the directory where the audio tracks have to be displayed. Is there any other way to display theese tracks ?.. :-P
Cannot be mounted as a *file*-system => contains no *files* => nothing to show in the *file* chooser. Everything is logical, don't you think? Please describe how you want it to work. When you insert CD in you home stereo it behaves similarly: everything is counted and you see the entire number of songs, and only after that you can choose to play some of them in the desired order (only if you have a fancy stereo).
Rhaaa you're boring me all of you. This aint a pebkac problem okay ? An audio cd have no filesystem that's right. An audio cd cannot be mounted that's right too. BUT THE AUDIO CD INPUT PLUGIN FOR XMMS, in its normal behaviour, make the tracks of an audio cd appear in the xmms file chooser, in the directory the plugin is configured for. So my xmms audio cd plugin is configured with /dev/cdrom for device and /mnt/cdrom for directory. So as i insert an audio cd in my cdrom drive, the tracks *must be displayed in the xmms file chooser in /mnt/cdrom*. Got it ? When they're in the file-chooser, i can add it to my xmms playlist so that xmms can play an audio cd ? isn't it wonderful ? And for your information, I dont have any stereo. All i got is my pc : tv, dvd, dolby5.1, divx. And please tell me, in the name of Linus, why do I see the tracks in xmms file chooser if I click on the 'add all file in directory' button when i'm in /mnt/cdrom ? Is anybody here not understanding ? Can all of you play with an audio cd, a cdrom drive and xmms to see there's a bug so that i wont have to post on this bug anymore ??
Okay, I can reproduce it here. The Audio CD input plugin's "scan_dir" function is never called when a new directory is entered from within the GTK file browser. Hence the plugin cannot know when the Audio CD directory is entered. It is only called when "OK", "Add selected files", or "Add all files" are clicked. [...] /mnt/cdrom appears to be the default config (for new installations). My XMMS is configured to access an Audio CD via $HOME/audio_cd, because /mnt/cdrom is used for mounting (haven't listened to Audio CDs for ages, btw). I think the bug report is not clear about the role of /mnt/cdrom, and the additional comments add to the confusion. Steps to reproduce: 1. Insert Audio CD, close tray. 2. rm -rf ~/.xmms 3. Press 'L' key (not SHIFT+L). 4. Go to /mnt/cdrom. => No audio tracks are listed in the "Files" view on the right. Clicking "OK" or "Add selected files" reads the track list from the CD and displays it in the "Files" view. It is important to NOT start XMMS in the Audio CD directory. When starting in the Audio CD dir, going up to parent dir and then back into the Audio CD dir again reproduces the problem, too.
At apodtele, I think you haven't understood how XMMS accesses ordinary Audio CDs. See /usr/share/doc/xmms-1.2.7/README. I have understood the problem, but not the relationship to /mnt/cdrom.
Conclusively, XMMS's GTK file browser should call an input plugin's "scan_dir" function upon entering new directories. No idea why it doesn't do that.
Don't you think that the statement of the problem is a lot clearer now after you bothered to do some investigation (to shut me up)? The original bug report is, well, just a bunch of wining.
This problem is caused by a combination of a patch to Gtk+ (gtk+-1.2.10-deletedir.patch) and some sligtly odd code in XMMS. As a bunch of other apps, XMMS messess around with the internals of the fileselection dialog. In this case XMMS detects changing of directories by hooking to the "changed" signal of the entry. I don't know why we do it in this way, this code was written a few years ago by someone else. Now, in all vanilla versions of Gtk+ 1.2.x this works out just fine, because the entry is always updated whenever we enter a directory. This has been changed in the RedHat version, and the entry is not changed if you enter a directory by using the mouse. If you enter it by tab-completion it works ok.
Many thanks, eagle-eye Harvard, for joining here! That was it. At least one line in patch21 is bad. With pristine gtk+, when one enters a directory with double-click, the name of the current directory is put into the "Selection:" text field and the line-edit field below is cleared. Patch21 changes this, so that the entered directory name is left over in the line-edit field. Not a good idea, because clicking okay then enters the same directory a second time (which is clearly wrong). At the same time, it causes the XMMS "hack" to fail due to this change. I'll attach a revised patch21, which can be used as a replacement for the patch in gtk+-1.2.10-15.src.rpm to rebuild a working libgtk. My patch includes a modification which re-enables entering directories with space/enter key. Would be great if reporter or anyone from Red Hat would change component to "gtk+".
Created attachment 58344 [details] replacement patch21 for source rpm
See http://bugzilla.gnome.org/show_bug.cgi?id=6791 for the background on the deletedir patch. (Most dup'ed GTK+ bug ever.) The basic idea of the deletedir patch is that manipulating the directory for the GUI with the mouse should not effect the contents of the entry. (I don't understand "Patch21 changes this, so that the entered directory name is left over in the line-edit field." the code isn't supposed to *ever* put a directory name selected with the mouse in the line edit field, and I can't get it to do it in testing.) While I haven't tried running it, I believe the "corrected" patch above basically makes the deletedir fix not fix the original bug. Unfortunately, the fact the established tradition of poking into the GTK+ file selection widgets guts means that its very hard to fix problems without breaking somehitng else. I think, on balance though, the fix in the deletedir patch is probably going to do people more good than the harm that got done to XMMS. Probably the best thing to do for now is to patch XMMS to watch the directory Clist as well and add an idle to rescan the directory when 2BUTTON_PRESS is clicked. (Assigning to myself, but leaving the component as XMMS, as I think this situation should be dealt with witha XMMS patch, not a GTK+ patch.)
Unfortunately, much more is involved: Cannot (!) reproduce losing the file name in Mozilla (1.0 rc2) with either patch. Mozilla works fine with regard to typing/selecting a file name and then browsing through arbitrary directories. Can reproduce losing the file name in "gedit" with the changed patch. Can reproduce losing the file name in Gimp with the changed patch. Cannot enter directories in Mozilla with the Return key with either patch. Can enter directories with space/return in Gimp with the changed patch only. Cannot enter directories in gedit using keys with either patch. Pressing return activates the "Ok" button regardless of widget focus. (Please kindly ignore the earlier comment you don't understand. It might be a temporary version that caused that behaviour at my end. Can't reproduce it now.)
Created attachment 58384 [details] Patch that implements Owen's suggestion
This patch implements Owen's suggestion about watching the directory clist. I already had a patch that instead of watching the entry and the directory clist connected to the "add" signal of the history_pulldown widget. That worked out ok, but it obviously depends on a lot of knowledge about how the internals of the fileselection dialog work. I think this patch is slightly better. Are there plans to merge the "deletedir" patch in Gtk+ proper?
Created attachment 58404 [details] I suck. Updated patch.
Michael - Diffing diffs, the change from the original deletedir diff to your patch is: @@ -129,7 +135,9 @@ + gtk_clist_get_text (GTK_CLIST (fs->dir_list), row, 0, &filename); + + if (filename && bevent && bevent->type == GDK_2BUTTON_PRESS) -+ gtk_file_selection_populate (fs, filename, FALSE, FALSE); ++ gtk_file_selection_populate (fs, filename, FALSE, TRUE); ++ else if (filename) ++ gtk_entry_set_text (GTK_ENTRY (fs->selection_entry), filename); } static void @@ -148,7 +156,7 @@ So, the two changes are: - If you double click on an entry then after it changes to the new directory, it deletes the filename from the entry. - if you single-click on directory in the directory list it puts that directory into the entry. If I'm not missing something, with your change it is impossible to change directories via the directory list with the mouse without losing the current filename. Which is exactly the problem the deletedir patch was supposed to fix. Hevard - Something similar to the deletedir patch is in GTK+-2.0.x. The plan is to merge the deletedir patch into GTK+-1.2.11 if I ever can find the time to do an official 1.2.11. Your patch looks like it will probably work (though glancing at it ... does it catch picking a directory from the history popdown?) The exact set of ways that a user can change the directory through the file selection interface in 1.2.x is: - Double click on a directory in the directory list - Hit <Tab> in the entry, triggering a completion that changes the directory - Pick a new directory from the history dropdown So if they all work, it works. (If I was trying to monitor the directory, I'd probably connect to these three events explicitely, rather than watch the changed signal on the entry and select_row, on the clist, which are more tenuously connected to directory changes.)
> (though glancing at it ... does it catch picking a directory from the history > popdown?) No, that's not handled. But, such a directory will never have subdirectories, and you can only go upwards with the history popdown, so in practice I don't think anyone will ever notice this problem. > (If I was trying to monitor the directory, I'd probably connect to these three > events explicitely, rather than watch the changed signal on the entry and > select_row, on the clist, which are more tenuously connected to directory > changes.) There is a problem with detecting <tab> presses, because the key-press-event is stopped by the file selection dialog. Or, maybe I've missed something fundamental here?
Owen, I added that I _am_ able to reproduce the regression caused by my changes. I do understand that this brings back a problem for apps like Gimp or gedit. However, since Mozilla does NOT lose the file name as described in the gnome.org bug report I wanted to pointed that out. And my other change (the line following "else") _repairs_ entering directories with space/enter while your patch kills that functionality, at least for XMMS. Other GTK apps are badly broken with regard to this, as I showed in previous comment. At this point I get back to my comment which you didn't understand earlier. If you rebuild gtk+-1.2.10-15 _without_ patch21, you can navigate through directories with space/enter just like with my changed patch. Space highlights a directory name, enter accepts it. If you add your patch21, it fixes the file name issue, but kills space/enter directory navigation. This should be dealt with somehow, too. Good that Haavard has a patch for the Audio CD plugin, but patch21 should not kill the ability to enter directories with space/enter.
Of course, if you want to fix that file name issue (with double-click browsing) at the cost of space/enter browsing, oh well, ...
Yeah, you can't connect to "key_press_event"; a hack-around that would work is to connect a signal handler to the "event" signal. The way GTK+ works is that first "event" is emitted, and if the handler doesn't return TRUE, then the specific event handler is emitted. But as long as your current patch works in practice it is almost certainly good enough. === a) mozilla doesn't use GtkFileSelection (Surely you noticed that their filesel looked completely different?) b) I think you are very unusual in navigating the GtkFileSel with the keyboard by putting the focus on the clist ... to even get there you have to <Shift>Tab out of the filesel, and there are all sorts of oddities that you will encounter ... like the space toggling the row selection, and having to hit <space> followed by <return> to enter a directory. (GTK+-2.0.0 is better - there is a mnemonic, and <space> to enter a directory works fine.) I'm pretty sure most people are either leaving the focus in the entry and using the (very complete) tab completion to navigate, or are navigating completely with the mouse. There is only so much "making a silk purse out of a pigs ear" that's worth it for the GTK+-1.2 file selection. The GTK+-2.0 is nicer in detail, if basically the same in general outline. For 2.4 we'll hopefully have something really nice. (You can try out the GTK+-2.0 by installing the 7.3 gtk2 packages and running 'testgtk'. Don't expect too much, but keynav is better.)
> a) mozilla doesn't use GtkFileSelection (Surely you noticed that their > filesel looked completely different?) Hehe, it was you who pointed to this URL (old, though) which uses Mozilla as a test-case: http://bugzilla.gnome.org/show_bug.cgi?id=6791 Mozilla is not an issue here. That's why I tested with Gimp and gedit. The more I play with XMMS' Audio CD plug-in, the less I like to use Konqueror for listening to Audio CDs. Enough said. Btw, I prefer Qt's QFileDialog anyway.
Just "cursor down" a few times to focus directory list view (tabbing here interferes with TAB-completion).
I still can't see this patch in the (null) beta. Any chance it gets accepted?
1.2.7-17.p (should appear in RawHide soon) includes the patch. Sorry for the delay ... got separated from other xmms bugs.