glib comments

[Scott Wheeler]

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 
around for):

<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 
> toolkit.

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.  
;-)

Cheers,

-Scott

-- 
Three words: you have no clue
-Slashdot