Lennart Poettering wrote:
> Haha. So the major 'advantage' of Phonon that it would allow replacing
> the backends as time progresses without breaking the KDE apps using
> them now officially is proven to be bogus. The KDE/Qt folks were so
> afraid of a media engine breaking API so that they created their
> abstraction thing and now break API of that one more often then the
> media engines themselves do.
KDE is going to support Phonon for at least the whole KDE 4 cycle (which is
planned to be quite long as neither Qt nor KDE sees an immediate need for an
API-breaking version) as part of the API compatibility promise, and there is
also strong active development ongoing on the KDE side, so it won't be
deprecated on the KDE side and chances are it will still be there in future
major versions of KDE (e.g. KDE 5) as well (though at that point, API
changes can happen). (But of course this development currently focuses on
the xine-lib backend, which is the backend KDE recommends. Though there are
developers from e.g. Mandriva interested in improving the GStreamer one,
too.)
What is likely to happen is that Phonon is going to be deprecated on the Qt
side, and Qt's bundled copy of Phonon might end up not getting updated, too.
But that's one of the reasons we decided to ship Phonon from its own SRPM
again in yesterday's meeting. Phonon possibly becoming deprecated in Qt is
completely irrelevant for KDE application developers as it is still the
preferred solution for multimedia in KDE and will remain so for the
foreseeable future.
There's a general rule in KDE: if there's a KDE class and a Qt class doing
the same thing, always use the KDE class unless it explicitly says it's
deprecated in favor of the Qt one. If Qt comes up with their own multimedia
framework, multimedia will just be one more instance of this rule.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
