The current ebuild for qt-phonon does not check qt-core and qt-gui for glib support. However, if qt-core and qt-gui are built without setting their "glib" USE flag, phonon won't work properly. Applications like the "music player" example will compile fine, but won't do anything useful at runtime because signal handling between qt and gstreamer doesn't seem to work at all. Glib support seems to be crucial for proper interaction with the gstreamer backend. To check this behaviour, compile qt-core / qt-gui without glib USE flag. Build the music player example (make sure to link it against qt-phonon, NOT a possibly present kde4-phonon). Start music player and try to add some mp3 files. -> The playlist will remain empty. Recompile qt-core / qt-gui with the glib USE flag set. Recompile music player example, add mp3 files, et voila: music player works.
Fixed in qt-phonon-4.4.1-r1.ebuild. Thanks for reporting!
I just found that bug report thanks to http://forums.gentoo.org/viewtopic-p-5196707.html . I built my Qt intentionally without glib since I read it would produce some severe performance problems with graphical effects and I don't need the glib support. qt-phonon depends "hard" on gstreamer and therefore now on Qt beeing built with glib. Sooo, do I understand it right that the _qt_-phonon ONLY supports gstreamer and therefore will _always_ be built with gstreamer/glib or is there another way to go?
I second the question in comment #2. I want to hard mask glib/gtk+ on my systems. Why the heck should their competition depend on them?
(In reply to comment #2) > Sooo, do I understand it right that the _qt_-phonon ONLY supports > gstreamer and therefore will _always_ be built with gstreamer/glib That is correct. There is no other way to use qt-phonon. You can opt to use media-sound/phonon (the KDE implementation) instead, which can use xine instead of gstreamer.
