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@ucsd.edu, 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.