On Thursday 17 September 2009 02:41:43 Kevin Kofler wrote: > Ryan Rix wrote: > > I'm currently trying to start a KDE beat for next week's Fedora Weekly > > News, and was hoping I could get a little clearing up on the whole state > > of QtMultimedia in Qt 4.6. > > I'd second Eike's recommendation not to mention Phonon yet, we don't have > all the information we'd like to have ourselves at this point. > > In any case, some of the things you wrote are incorrect: > > What I know: > > * Qt pulled Phonon into its API for the 4.4 release. > > Right. > > > * QtMobility is creating a second Multimedia API which will be lower > > level than Phonon which will be in Qt 4.6 under a QtMultimedia namespace. > > Wrong, you're mixing up 2 things: > * QtMobility is creating a second Multimedia API which they see as > replacing Phonon. It will be on basically the same level as Phonon (though > a backend wrapping Phonon is being considered). > * There is a low-level (direct PCM access) audio API which will be in Qt > 4.6 under a QtMultimedia namespace, complementing Phonon (which still > doesn't have a low-level API (one was started on a work branch, but never > made it into trunk, and it only has an ALSA backend, more would be needed > for portability)). The QtMultimedia stuff appears to have backends for all > Qt platforms. > > Those 2 sets of classes are separate (though they may (or may not) end up > merged under the QtMultimedia namespace in a future version of Qt). > > > * Fedora-KDE will be meeting next week with the upstream (kde) developers > > regarding the future of Phonon in KDE. > > Not exactly true either. > > We will try to gather feedback from upstream over the next week and discuss > the matter again next week in our meeting based on that feedback. (Another > reason why this shouldn't be covered this week, the discussion got > postponed to next week at the earliest.) > > > * Some Fedora-KDE members (Kevin, Sho_, Rex(?)) believe the API to be > > inferior > > It's not just inferior, it's also not ready yet and will be incompatible > with Phonon, so KDE apps will continue using Phonon for the foreseeable > future. > > > and may end up becoming the main Multimedia API in Qt > > That indeed seems to be the case. > > > as Phonon becomes older and older (via IRC logs) > > Phonon itself is actively developed, what we're worried about is that the > copy inside Qt will be bitrotting. > > > What I don't know: > > Well, we don't know for sure either. But as far as I know: > > * What does this mean for KDE for KDE now, KDE4.4 (which will be on Qt > > 4.6?) and the future of the project in general? > > Not much, KDE will just continue using Phonon. > > Our worries are about the future of Qt's bundled Phonon (which is the > Phonon we're currently shipping in Rawhide, also because of the circular > Qt- > > >Phonon->Qt dependency due to QtWebKit using Phonon) and of the Phonon- > > GStreamer backend (which is primarily maintained by Qt Software). > > > * Will KDE apps begin using QtMultimedia (or a KDE derivative) over > > Phonon? > > No. > > > * How do Fedora-KDE developers feel about this possible change and > > the new API in general? There is, as always, both sides to the issue and > > I want to capture both. > > My personal opinion: It just reinvents the wheel for no reason and is yet > another incompatible API. This continues the pattern of Qt reinventing > inferior versions of kdelibs functionality, ending what was marketed as the > first success story of KDE-Qt cooperation. We're back to the times of KDE > and Qt containing duplicate functionality because KDE's version was there > first and is better in many ways. :-( > > The QtMobility folks claim Phonon is incomplete because it's missing > features X, Y and Z, but when you research things, you find out that X is > already implemented in Phonon trunk which Qt doesn't seem to be interested > in merging, Y is being implemented and Z is planned, but nobody bothered > working on implementing it (so the QtMobility folks could have done it > within Phonon instead of reinventing the wheel). For example, extracting > single frames from a video (useful e.g. for thumbnailing) is one such > "feature X". On the other hand, their stuff isn't even usable yet. > > > Sorry if I sound ignorant on the subject (I am) and thanks for helping me > > out. This'll be in FWN next week under the (new) KDE beat if I can get a > > handle on this issue. > > To be honest, I think that if FWN wants to cover KDE stuff, somebody who > follows the discussions on #fedora-kde and knows what they mean will have > to do it. (For example, I believe everything I wrote about Phonon in this > mail was said on #fedora-kde at some point.) Somebody as confused as you > are will just misinform users. :-( Sorry for being blunt? I think if Ryan just sends us his article before publishing it and we do review, it would be best. We don't have time to write our own but we can say - correct this, change this and even it's not bad if someone out of our community is independently writing about our stuff. Well, Ryan, Kevin - do you think it could work? I'm glad we're going to be covered in FWN! Jaroslav > Kevin Kofler > > _______________________________________________ > fedora-kde mailing list > fedora-kde at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/fedora-kde > New to KDE4? - get help from http://userbase.kde.org > -- Jaroslav ?ezn?k <jreznik at redhat.com> Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/