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