wheeler at kde.org
Tue Feb 25 03:27:46 GMT 2003
On Tuesday 25 February 2003 2:42, Neil Stevens wrote:
> The library naming really sidesteps the issue. If glib 3.0 comes out 3
> months after KDE 4 comes out, and GStreamer development moves to it, then
> KDE gets stuck with an unmaintained version of glib and GStreamer for the
> life of KDE 4. The compatibility within a version is nice, but we also
> need a library that will keep compatible for long stretches of time.
> But, if glib versions will stay compatible for years, then I doubt that'd
> be a problem. The issue then becomes GStreamer's own compatibility.
Well, I think it's reasonable to assume based on my interaction with these
guys that if KDE is adopting GStreamer that they'd be willing to talk about
compatibility through KDE release cycles.
In fact, I just typed the above in on IRC and the answer was (which Neil was
<omega> wheels: yes, just like we're already committed to
compatibility through the 0.6.x cycle for gnome2.2
<omega> kde would be no different in that sense
<omega> that's what's supposed to always happen when you ship a program as
part of a larger package
<vektor> Gstreamer needs KDE as much as KDE needs gstreamer, I don't think you
can get around that.
<omega> if KDE needs it consistent, just like GNOME needs it consistent, we
obviously treat that as a priority
[with some of my formatting]
> But linking isn't my complaint. Developing is my complaint. KDE
> developers shouldn't have to be glib developers. KDE developers should be
> able to extend the KDE-chosen media system without learning some C
And they should have to be MCOP developers? Just an example, I know you
already qualified your opinion on aRts and some of the relative difficulty in
developing for it.
Ok, another question (though not specifically for you) -- is this just a
idealogical answer or are there actually other developers on here that would
not be willing to work in a GObject based environment? I'm no GObject
cheerleader, in fact I've never used it, but I feel confident that I could
learn it with a similar amount of ease (or difficulty rather) to the toolkit
used by any other media system. Are there real (not theoretical) developers
here that would consider implementing a codec in a non-GObject C framework
that would not consider that in a GObject based C framework? Keep in mind
that it seems that most (where most == more than aRts supports) of the work
is already done in the codecs.
And part two: *if* Tim or someone else was able to make it possible to extend
GStreamer just using the Qt bindings, what say you then?
Oh, and something else I had in #gstreamer today:
Basically my logic is: (1) Gnome 2.4 will be before KDE 4.0. (2) GStreamer /
Gnome claims that GStreamer will be stable at that point. (3) We're going to
end up using something with C, since well, that's all of our options. (4) If
we're using C, we might as well use glib. (5) If we're going to use C and
possibly glib, it makes sense to focus the two large desktop projects on the
same media backend, sofar as that is possible. (6) This will hopefully avoid
some of the problems with aRts by setting a standard on the Linux desktop and
helping to encourage a strong cross-desktop multimedia devel community.
It should also be pointed out that GStreamer can *right now* output to aRts
using the artsdsink. From the CLI this does the trick now:
gst-launch filesrc location="foo.mp3" ! spider ! artsdsink
Oh, and real docs: http://www.gstreamer.net/docs/gstreamer/book1.html
This ends the strange collection of information section of this presentation.
Three words: you have no clue
More information about the kde-multimedia