faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
|
kdom
by Filip on Thursday 11/Aug/2005, @13:11
|
also there's a lot happening on kdom. As far as I understood kdom is a new layer that will serve as a base for khtml2, ksvg, mathml?, .. Apple already started adopting it for Webcore!
And once kdom and khtml2 are a bit more finished I suppose lots of merges will happen from Webcore back to kde now that webcore cvs history is available.
Also there is being worked on a abstraction layer for multimedia playback, it is called kdemm. Once it's finished you'll be able to choose between different backends (like gstreamer for instance) |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: kdom
by Andre Somers on Thursday 11/Aug/2005, @15:01
|
Let me get this strait. The idea of the multimedia layer is that we get a layer on top of the existing backends? That would mean that an application is talking to kdemm, which is talking to Arts, which is talking to OSS, which is talking to the driver, which is talking to the hardware. Right? Damn... that's 4 layers to cross before the sound goes from the application to the actual hardware. Wouldn't it be better to sometimes just make a *choice* for a framework? Maybe, may be not
Anyway, I am completely ignorant about how this stuff actually works, so I probably should just shut up.
|
[
Reply To This | View ]
|
Re: kdom
by ac on Thursday 11/Aug/2005, @16:33
|
> Anyway, I am completely ignorant about how this stuff actually works, so I probably should just shut up.
Indeed.
|
[
Reply To This | View ]
|
Re: kdom
by canllaith on Thursday 11/Aug/2005, @16:37
|
Chances are, aRts will be gone for KDE4 and a completely new multimedia framework will be put in place.
|
[
Reply To This | View ]
|
Re: kdom
by cm on Thursday 11/Aug/2005, @17:31
|
> The idea of the multimedia layer is that we get a layer on top of the existing backends?
The idea isn't to have another layer in order to have another layer but to avoid another case of "We're stuck with an unmaintained or no-longer-optimal multimedia framework for the whole release cycle for binary compatibility reasons, i.e. for years to come.".
But I guess the kdemm concept will have to prove its viability anyway before it's released.
|
[
Reply To This | View ]
|
Re: kdom
by Carsten Niehaus on Friday 12/Aug/2005, @00:20
|
The idea of KDEMM is also to let the user have a choice. I for one am using xine as a backend for amarok, the only sound-app I am using. Systemsound is disabled and so on. But a friend of mine is doing streaming across networks or something like that and will need MAS for that (I hope MAS was the network-thing... not 100% sure). Well, why should I be forced to use a heavyweight soundserver with network-stuff and so on?
Furthermore KDEMM will make it easy for the application developer: The application will always call something like play->( soundfile ), no matter which backend the user is using...
In a perfect world situation KDE will ask the user once if he needs networkstuff or not and then choose the backend for him. Joe User doesn't know what gstreamer or xine or ... is so that layer should be hidden from him.
Last not least you never know what happens with gstreamer in 1 year from now. They broke binary compatibility ever 6 to 8 month in the past but KDE4 will need BC for about 3 to 5 years. Even if the gstreamer folks would release version 1.0 tomorrow, who would guarantee BC for 4 years? No one. With KDEMM you can work around this problem as the KDE-apps would use and link against KDEMM and not directly against gstreamer. Of course the very same is true for MAS, xine and so on.
The final point is that it might be that the day after the release of KDE 4.0 a super-cool light-weight all purpose soundsystem pops up and we all want to use it... Without KDEMM you couldn't use it but with it it is just another backend. Sure, you would have to wait until KDE provides the "bindings" for it, but that will happen pretty soon.
|
[
Reply To This | View ]
|
Re: kdom
by claes on Friday 12/Aug/2005, @01:27
|
Wrapping one api on top of another has serious disadvantages too. Either the wrapping api completely exposes the underlying api, but perhaps with different semantics, and then it will be hard to port it to other underlying apis. Or it can expose a reasonable subset. In this case you will not get full access to functionality in the underlying API.
When the underlying API is stable, well thought out, and offers advanced features, my belief is that the best you can do is expose it and let application developers take advantage of it directly. Wrapping for portability comes with a price.
|
[
Reply To This | View ]
|
Re: kdom
by Anonymous on Friday 12/Aug/2005, @01:49
|
The "reasonable subset" is the idea and the way to go. For more special stuff than eg playing audio (notification, music) the single applications have to support the backend directly themselves.
|
[
Reply To This | View ]
|
Re: kdom
by Aaron J. Seigo on Friday 12/Aug/2005, @21:53
|
well, multimedia is an interesting topic because 98% of applications[1] only need a specific and very limited subset of functionality: play, pause, stop, record, etc... what is important to these applications is that it is easy to do this programmatically, that it's widely portable and that latency is low enough that the user doesn't notice the time between action and reaction.
these needs are very different than one sees in an actual media creation app, of course, where you want perfect latency handling ("no perceptible delay" isn't good enough anymore) and access to a wide and complex array of media functionality.
unfortunately for regular app developers, the best media systems are designed by people very familiar with media and so they tend to end up being complex beasts to deal with unless you too are a media developer.
by providing a thin layer we can get the ease of use necessary and the portability between media systems. by keeping the layer thin, it's also possible to keep it performant. and all media systems support the basics needed here (play, pause, etc)
by recommending a given media engine, we can also give something for serious content creation app developers to target.
so i think the path the kdemm developers are taking makes a TON of sense. given the above explanation, would you agree?
[1] 64% of statistics are invented on the spot by winged mammals
|
[
Reply To This | View ]
|
Re: kdom
by cl on Friday 12/Aug/2005, @23:42
|
> by providing a thin layer we can get the ease of use necessary and the portability between media systems. by keeping the layer thin, it's also possible to keep it performant. and all media systems support the basics needed here (play, pause, etc)
And the multimedia engine layer in amaroK proves that this is doable.
|
[
Reply To This | View ]
|
Re: kdom
by cl on Friday 12/Aug/2005, @00:33
|
> [..]"We're stuck with an unmaintained or no-longer-optimal multimedia framework"[..]
Not only that. It's also this other mm framework offers something (for example multimedia over network) that _I_ need but I can't use it because KDE choosed something else.
> But I guess the kdemm concept will have to prove its viability anyway before it's released
Yes.
|
[
Reply To This | View ]
|
Re: kdom
by Segedunum on Friday 12/Aug/2005, @07:11
|
A proper and sensible abstraction for KDEMM is the right way to go. Would you rather do something like play->(soundfile), or link directly and heavily into an MM framework like GStreamer? At the moment, using GStreamer means strapping yourself to it, using the C API and creating a lot of god-awful, unmaintainable code. You would end up in a worse situation than there is with arts at the moment.
There are certainly disadvantages to using wrappers and layers, but a rule about layers is that every one should add value. This one certainly does.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
