Bug 65173 - Xmms dont see audio tracks in the file chooser.
Summary: Xmms dont see audio tracks in the file chooser.
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xmms
Version: 7.3
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: Owen Taylor
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-05-19 09:31 UTC by Anvil
Modified: 2008-05-01 15:38 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-01-14 22:14:48 UTC
Embargoed:


Attachments (Terms of Use)
replacement patch21 for source rpm (5.30 KB, patch)
2002-05-24 01:02 UTC, Michael Schwendt
no flags Details | Diff
Patch that implements Owen's suggestion (2.79 KB, patch)
2002-05-24 09:44 UTC, Håvard Kvålen
no flags Details | Diff
I suck. Updated patch. (2.92 KB, patch)
2002-05-24 12:06 UTC, Håvard Kvålen
no flags Details | Diff

Description Anvil 2002-05-19 09:31:19 UTC
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.

Comment 1 Anvil 2002-05-19 09:46:06 UTC
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.

Comment 2 Alexei Podtelezhnikov 2002-05-19 19:09:26 UTC
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.

Comment 3 Anvil 2002-05-19 19:12:42 UTC
You're very wrong. Audio CD cannot be mounted.


Comment 4 Michael Schwendt 2002-05-20 12:25:22 UTC
Why do you go into /mnt/cdrom when it is an Audio CD?

Comment 5 Anvil 2002-05-20 16:56:08 UTC
*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

Comment 6 Alexei Podtelezhnikov 2002-05-20 19:17:51 UTC
 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).

Comment 7 Anvil 2002-05-20 19:40:50 UTC
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 ??


Comment 8 Michael Schwendt 2002-05-20 20:30:13 UTC
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.


Comment 9 Michael Schwendt 2002-05-20 20:36:49 UTC
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.

Comment 10 Michael Schwendt 2002-05-20 20:40:16 UTC
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.


Comment 11 Alexei Podtelezhnikov 2002-05-20 23:30:42 UTC
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.

Comment 12 Håvard Kvålen 2002-05-21 16:30:30 UTC
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.

Comment 13 Michael Schwendt 2002-05-24 01:01:32 UTC
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+".


Comment 14 Michael Schwendt 2002-05-24 01:02:32 UTC
Created attachment 58344 [details]
replacement patch21 for source rpm

Comment 15 Owen Taylor 2002-05-24 02:20:45 UTC
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.)


Comment 16 Michael Schwendt 2002-05-24 09:14:49 UTC
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.)

Comment 17 Håvard Kvålen 2002-05-24 09:44:19 UTC
Created attachment 58384 [details]
Patch that implements Owen's suggestion

Comment 18 Håvard Kvålen 2002-05-24 09:52:47 UTC
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?

Comment 19 Håvard Kvålen 2002-05-24 12:06:46 UTC
Created attachment 58404 [details]
I suck.  Updated patch.

Comment 20 Owen Taylor 2002-05-24 14:31:51 UTC
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.)


Comment 21 Håvard Kvålen 2002-05-24 15:04:12 UTC
> (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?

Comment 22 Michael Schwendt 2002-05-24 19:05:52 UTC
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.


Comment 23 Michael Schwendt 2002-05-24 19:12:03 UTC
Of course, if you want to fix that file name issue (with double-click browsing)
at the cost of space/enter browsing, oh well, ...


Comment 24 Owen Taylor 2002-05-24 19:30:55 UTC
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.)


Comment 25 Michael Schwendt 2002-05-24 19:55:21 UTC
> 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.


Comment 26 Michael Schwendt 2002-05-24 19:57:48 UTC
Just "cursor down" a few times to focus directory list view (tabbing here
interferes with TAB-completion).


Comment 27 Håvard Kvålen 2002-08-31 19:10:23 UTC
I still can't see this patch in the (null) beta.  Any chance it gets accepted?

Comment 28 Owen Taylor 2003-01-14 22:14:48 UTC
1.2.7-17.p (should appear in RawHide soon) includes the patch. 
Sorry for the delay ... got separated from other xmms bugs.



Note You need to log in before you can comment on or make changes to this bug.