aRts vs JACK

Oliver Bausinger bausi at everest.mathematik.uni-tuebingen.de
Mon Feb 24 16:59:39 GMT 2003


On Mon, 2003-02-24 at 17:37, Neil Stevens wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Monday February 24, 2003 08:32, Oliver Bausinger wrote:
> > Hi all,
> >
> > I'm following this with much interest.
> >
> > On Mon, 2003-02-24 at 16:56, Neil Stevens wrote:
> > > > Currently I however refuse to consider depending aRts on a GUI
> > > > toolkit, whereas glib would only be a moderately sized C portability
> > > > library. In fact, I would even think that depending Qt on glib would
> > > > be a very wise decision interoperability wise, because it would open
> > > > a much easier path towards in-process coexistence of GNOME and KDE
> > > > code snippets.
> > >
> > > In theory, glib is not a GUI toolkit, no. But in practice, glib is a
> > > foundation of the GNOME system, and is not used in KDE.  This puts KDE
> > > developers at a severe disadvantage if the KDE media system makes you
> > > use it.
> >
> > Why? (Just for the sake of being different to GNOME? ... how silly)
> >
> > What are the technical reasons for not wanting to depend on glib as an
> > object type system. From what I can see, it is
> >
> > - small (can't really say that about libqt-mt.so)
> 
> Qt is zero cost in the KDE media system, as we already have it.  In terms 
> of absolute cost to use, glib is infinitely higher than Qt.  Try again.
> 
> > - portable (even under Windows, not sure)
> > - mature (iteration 2.x.x)
> > - well tested and used (GStreamer and more)
> 
> Who cares?
> 
> > KDE has no problem to rely on GNOME's libxml/libxslt, nor has it a
> > problem to rely on many 3rdparty libs. There's nothing special about
> > glib.
> 
> You miss the entire point.  KDE's APIs don't force you to use libxml.  
> libxml is internal.  KDE apps in general don't even use it.  They use Qt's 
> XML support.  The one publlc XML API (KXMLGUI) even uses it.
> 
> > So, perhaps someone can give me a little more technical insight about
> > possible problems.
> 
> The problem is that we already have an object system.  A second one gets in 
> the way.  One obligation in choosing a KDE system is to ensure development 
> is efficient.

Well, things can obviously be wrapped in a qt-friendly way. Look a Tim
Jansens qgst bindings (apropos: great job, Tim. The other day I just
looked at juk's gstreamer player code and thought: wow, that's nice and
elegant :-)

Greetings
Bausi

-- 
Oliver Bausinger <bausi at everest.mathematik.uni-tuebingen.de>



More information about the kde-multimedia mailing list