<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Why Phonon is a broken wheel</title>
	<atom:link href="http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/</link>
	<description>Just another GNOME Blogs weblog</description>
	<lastBuildDate>Thu, 05 Nov 2009 06:04:19 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Jamie McCracken</title>
		<link>http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/comment-page-1/#comment-349</link>
		<dc:creator>Jamie McCracken</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/#comment-349</guid>
		<description>Have to agree - I cant see the point of abstracting the abstraction (which is probably only being done to not have glib dependency in KDE). I can understand their dislike of Glib&#039;s duplication and the somewhat absurdity of the hackish GObjects but as you say this can be wrapped away in QT bindings.&lt;p/&gt;In the interests of freedesktop viability, I would love to see Gnome include QT (the newer leaner cut down version) and KDE include Glib  in their respective platforms. Its almost imposible to produce beneficial freedesktop software without needing either Glib/QT abstractions for things like mainloops, threads, DBUS connectivity etc.&lt;p/&gt;IMO, KDE has enough work to do with getting KDE4 out before Vista rather than having to waste time abstracting away things like HAL, GStreamer and other freedesktop stuff.&lt;p/&gt;</description>
		<content:encoded><![CDATA[<p>Have to agree &#8211; I cant see the point of abstracting the abstraction (which is probably only being done to not have glib dependency in KDE). I can understand their dislike of Glib&#8217;s duplication and the somewhat absurdity of the hackish GObjects but as you say this can be wrapped away in QT bindings.
<p />In the interests of freedesktop viability, I would love to see Gnome include QT (the newer leaner cut down version) and KDE include Glib  in their respective platforms. Its almost imposible to produce beneficial freedesktop software without needing either Glib/QT abstractions for things like mainloops, threads, DBUS connectivity etc.
<p />IMO, KDE has enough work to do with getting KDE4 out before Vista rather than having to waste time abstracting away things like HAL, GStreamer and other freedesktop stuff.
<p />
]]></content:encoded>
	</item>
	<item>
		<title>By: Janne</title>
		<link>http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/comment-page-1/#comment-350</link>
		<dc:creator>Janne</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/#comment-350</guid>
		<description>So, basically we have a GStreamer-developer telling everyone that Phonon is a bad idea, and that they should just use GStreamer instead?&lt;p/&gt;Well, color me surprised!</description>
		<content:encoded><![CDATA[<p>So, basically we have a GStreamer-developer telling everyone that Phonon is a bad idea, and that they should just use GStreamer instead?
<p />Well, color me surprised!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jon Cooper</title>
		<link>http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/comment-page-1/#comment-351</link>
		<dc:creator>Jon Cooper</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/#comment-351</guid>
		<description>@ Janne:&lt;p/&gt;Is the point not that Gstreamer is one of the backends Phonon is designed to abstract, but abstracting is pointless when applications will no doubt require access to the low level bits and bytes. The abstraction will get messy and require hacks for each supported &quot;pluggable&quot; backend.</description>
		<content:encoded><![CDATA[<p>@ Janne:
<p />Is the point not that Gstreamer is one of the backends Phonon is designed to abstract, but abstracting is pointless when applications will no doubt require access to the low level bits and bytes. The abstraction will get messy and require hacks for each supported &#8220;pluggable&#8221; backend.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tim Beaulen</title>
		<link>http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/comment-page-1/#comment-352</link>
		<dc:creator>Tim Beaulen</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/#comment-352</guid>
		<description>Quote Jamie McCracken:&lt;br/&gt;&quot;I cant see the point of abstracting the abstraction (which is probably only being done to not have glib dependency in KDE).&quot;&lt;p/&gt;Wrong, the point is to have a stable API during the lifetime of KDE 4. GStreamer probably can&#039;t provide that.&lt;p/&gt;It also lets the user choose whatever he or she wants. If a user likes Xine more than GStreamer, he or she can choose to use it.&lt;p/&gt;&lt;p/&gt;@ Christian Schaller&lt;p/&gt;Phonon is intended for the usual desktop applications. Playback of multimedia, recording and some simple effects.&lt;br/&gt;I don&#039;t think it&#039;s intended to be used in professional multimedia applications as those applications do have very different needs.&lt;p/&gt;It&#039;s like saying that GTK or Qt is not good enough for multimedia because they don&#039;t contain a good enough multimedia api. That&#039;s why you have GStreamer.&lt;br/&gt;</description>
		<content:encoded><![CDATA[<p>Quote Jamie McCracken:<br />&#8220;I cant see the point of abstracting the abstraction (which is probably only being done to not have glib dependency in KDE).&#8221;
<p />Wrong, the point is to have a stable API during the lifetime of KDE 4. GStreamer probably can&#8217;t provide that.
<p />It also lets the user choose whatever he or she wants. If a user likes Xine more than GStreamer, he or she can choose to use it.
<p />
<p />@ Christian Schaller
<p />Phonon is intended for the usual desktop applications. Playback of multimedia, recording and some simple effects.<br />I don&#8217;t think it&#8217;s intended to be used in professional multimedia applications as those applications do have very different needs.
<p />It&#8217;s like saying that GTK or Qt is not good enough for multimedia because they don&#8217;t contain a good enough multimedia api. That&#8217;s why you have GStreamer.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brad Griffith</title>
		<link>http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/comment-page-1/#comment-353</link>
		<dc:creator>Brad Griffith</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/#comment-353</guid>
		<description>@Tim Beaulen: If Phonon is really just for standard playback/other simple desktop applications, then this part of Christian&#039;s post seems all the more relevant:&lt;p/&gt;&quot;One scenario I know have been contemplated is using Phonon, but at the same time saying that GStreamer is the recommended framework if you want to do something outside of the scope of Phonon.&quot;&lt;p/&gt;I think the _possible_ benefits of sanctioning GStreamer as the multimedia backend for non-Phonon-based apps are many, but what would you think of giving a stamp of approval like that to non-Phonon apps?  Any hesitation I have about it is squashed by the fact that GStreamer is really the only viable multimedia framework for things like video/audio editors at the moment (and the forseeable future).</description>
		<content:encoded><![CDATA[<p>@<a href="http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/#comment-445">Tim Beaulen</a>: If Phonon is really just for standard playback/other simple desktop applications, then this part of Christian&#8217;s post seems all the more relevant:
<p />&#8220;One scenario I know have been contemplated is using Phonon, but at the same time saying that GStreamer is the recommended framework if you want to do something outside of the scope of Phonon.&#8221;
<p />I think the _possible_ benefits of sanctioning GStreamer as the multimedia backend for non-Phonon-based apps are many, but what would you think of giving a stamp of approval like that to non-Phonon apps?  Any hesitation I have about it is squashed by the fact that GStreamer is really the only viable multimedia framework for things like video/audio editors at the moment (and the forseeable future).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/comment-page-1/#comment-354</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/#comment-354</guid>
		<description>@ Brad Griffith&lt;p/&gt;It makes no sense for KDE to define a &quot;standard&quot; for programs that can not use Phonon for some reason. Most, if not all programs that are included in KDE will be able to use Phonon.&lt;p/&gt;Special programs, that are developed outside KDE (but use KDE api&#039;s) are the responsibility of the developers of those programs. If they want to use Xine instead of GStreamer, that&#039;s their choice, not KDE&#039;s choice.</description>
		<content:encoded><![CDATA[<p>@ Brad Griffith
<p />It makes no sense for KDE to define a &#8220;standard&#8221; for programs that can not use Phonon for some reason. Most, if not all programs that are included in KDE will be able to use Phonon.
<p />Special programs, that are developed outside KDE (but use KDE api&#8217;s) are the responsibility of the developers of those programs. If they want to use Xine instead of GStreamer, that&#8217;s their choice, not KDE&#8217;s choice.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brad Griffith</title>
		<link>http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/comment-page-1/#comment-355</link>
		<dc:creator>Brad Griffith</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/#comment-355</guid>
		<description>@anonymous&lt;br/&gt;If that is the position that you want to take, I believe (along with Christian, if I am reading him properly) that it will be to the disadvantage of the KDE community.&lt;br/&gt;    Firstly, as far as the basic playback needs go, most users can&#039;t even tell the difference between xine playing an MP3 and gstreamer playing an MP3.  It should be irrelevant and the most expedient technical solution should be taken.  And have a standardized framework would be more expedient than any marginal advantage one framework would have over another.&lt;br/&gt;    And secondly, for the apps outside of KDE base (and I suppose we&#039;re assuming KDE won&#039;t ever officially incorporate a video editor/audio editor/streaming server/etc.) it would benefit the community and the developers, again, to standardize on a framework (the only viable option currently being GStreamer).  It&#039;s not as if developers outside the respective GNOME and KDE cathedrals can&#039;t choose to cooperate to better the community.  It&#039;s about time they did, so we can stop all the foolish duplication of effort and move forward as quickly as our community has the potential.</description>
		<content:encoded><![CDATA[<p>@anonymous<br />If that is the position that you want to take, I believe (along with Christian, if I am reading him properly) that it will be to the disadvantage of the KDE community.<br />    Firstly, as far as the basic playback needs go, most users can&#8217;t even tell the difference between xine playing an MP3 and gstreamer playing an MP3.  It should be irrelevant and the most expedient technical solution should be taken.  And have a standardized framework would be more expedient than any marginal advantage one framework would have over another.<br />    And secondly, for the apps outside of KDE base (and I suppose we&#8217;re assuming KDE won&#8217;t ever officially incorporate a video editor/audio editor/streaming server/etc.) it would benefit the community and the developers, again, to standardize on a framework (the only viable option currently being GStreamer).  It&#8217;s not as if developers outside the respective GNOME and KDE cathedrals can&#8217;t choose to cooperate to better the community.  It&#8217;s about time they did, so we can stop all the foolish duplication of effort and move forward as quickly as our community has the potential.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cyrille Berger</title>
		<link>http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/comment-page-1/#comment-356</link>
		<dc:creator>Cyrille Berger</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/#comment-356</guid>
		<description>Anyway, what the difference between phonon and a kde/qt binding with gstreamer ? except that in the future (even in the present, after all), it would be possible to get ride of gstreamer, if it dies or something better come up ?</description>
		<content:encoded><![CDATA[<p>Anyway, what the difference between phonon and a kde/qt binding with gstreamer ? except that in the future (even in the present, after all), it would be possible to get ride of gstreamer, if it dies or something better come up ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Heretic</title>
		<link>http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/comment-page-1/#comment-357</link>
		<dc:creator>Heretic</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/#comment-357</guid>
		<description>The point is not to depend on one system. Thats what happened with arts, if Gstreamer ever became unmaintained and fell the way arts did then kde would be stuck with it, much like its stuck with arts until kde4. Phonon will allow users to have a choice of using gstreamer, jack, nmm etc. The &quot;lets all just use Gstreamer&quot; mantra is just hilarious. Plus gstreamer .10 isn&#039;t really a stable quality release and is missing features (dvd). I like the way kde is moving along with this, a dependency on one thing and one thing only is just riddled with failure. Kde seems to be moving along at a rapid pace with phonon, solid, plasma and tenor. I don&#039;t see anything even remotly as cool as those projects on the gnome side. So instead of whining on how &quot;its not gstreamer&quot;, fix the stuff gstreamer doesn&#039;t have and make it the one clear choice. As of now I wouldn&#039;t use gstreamer, just too unstable and has too many quirks to deal with.</description>
		<content:encoded><![CDATA[<p>The point is not to depend on one system. Thats what happened with arts, if Gstreamer ever became unmaintained and fell the way arts did then kde would be stuck with it, much like its stuck with arts until kde4. Phonon will allow users to have a choice of using gstreamer, jack, nmm etc. The &#8220;lets all just use Gstreamer&#8221; mantra is just hilarious. Plus gstreamer .10 isn&#8217;t really a stable quality release and is missing features (dvd). I like the way kde is moving along with this, a dependency on one thing and one thing only is just riddled with failure. Kde seems to be moving along at a rapid pace with phonon, solid, plasma and tenor. I don&#8217;t see anything even remotly as cool as those projects on the gnome side. So instead of whining on how &#8220;its not gstreamer&#8221;, fix the stuff gstreamer doesn&#8217;t have and make it the one clear choice. As of now I wouldn&#8217;t use gstreamer, just too unstable and has too many quirks to deal with.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brad Griffith</title>
		<link>http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/comment-page-1/#comment-358</link>
		<dc:creator>Brad Griffith</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/uraeus/2006/05/11/why-phonon-is-a-broken-wheel/#comment-358</guid>
		<description>@Cyrille Berger&lt;br/&gt;I think the primary difference would simply be that phonon can&#039;t really encompass the full functionality of something like Gstreamer and still be capable of creating any really interesting/complicated apps.  &lt;br/&gt;    And the odds that a new framework would fit into phonon well enough to not require major changes to phonon and still be able to create complicated apps are too miniscule to even be worth considering.  I think the point is that wrapping multimedia frameworks for anything more complicated than a music/video player is futile.  And the benefits of something like phonon for simple playback apps are dubious at best (seeing as the frameworks all pretty much do the exact same things and any one of them could be enhanced to do what the other can without too much effort).</description>
		<content:encoded><![CDATA[<p>@Cyrille Berger<br />I think the primary difference would simply be that phonon can&#8217;t really encompass the full functionality of something like Gstreamer and still be capable of creating any really interesting/complicated apps.  <br />    And the odds that a new framework would fit into phonon well enough to not require major changes to phonon and still be able to create complicated apps are too miniscule to even be worth considering.  I think the point is that wrapping multimedia frameworks for anything more complicated than a music/video player is futile.  And the benefits of something like phonon for simple playback apps are dubious at best (seeing as the frameworks all pretty much do the exact same things and any one of them could be enhanced to do what the other can without too much effort).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
