Neil Stevens neil at qualityassistant.com
Fri Feb 28 19:10:50 GMT 2003

Hash: SHA1

(You know, if you want to be in kdemultimedia, it'd be a good idea if you'd 
CC the list on this matter)

On Friday February 28, 2003 11:00, Scott Wheeler wrote:
> On Friday 28 February 2003 19:25, Neil Stevens wrote:
> > Bu supplying its own decoders it duplicates the functionality we get
> > from mpeglib.
> JuK doesn't supply it's own decoders.  It uses aRts and GStreamer for
> that.

Well, you should have said so on your page then!

> > > well, obviously, since it's another media player interface, though
> > > arguably of a completely different category.
> >
> > More specific than that.  Noatun's optimized for the same uses juk is:
> > music.  I'd not argue juk duplicates aktion, kaboodle, or kscd
> Sure, it's optimized for music, as is Noatun.  But users and developers
> of KDE and every other platform seem to support the notion that having
> both is a good thing.  (See my initial post for examples.)

I didn't say if it was good or bad.

> > > > KFileMetaInfo,
> > >
> > > does this refer to it's mp3 tag reading/editting? or?
> JuK uses KFileMeta info.  The only exception is for ID3v2 tags, which I
> am working on supporting (without id3lib) in KFMI for KDE 3.2.  Trust
> me, I hate id3lib more than you can possibly imagine (see my posts on
> KDE-MM a couple months ago for more information).

You should have said so on the page then!

> > > > aRts,
> > >
> > > i thought it used aRts? what part of aRts does it duplicate?
> >
> > Its multiple output methods duplicate what we do in artsd.  Noatun
> > could move the same outputs if the output code were moved into artsd
> > instead.
> Uhm, huh?  (/me makes a confused face)  This is done by a simple
> abstract class, "Player" which has two concrete implementations -- one
> for aRts and one for GStreamer.  It requires aRts and if GStreamer is
> available at compile time, makes it selectable at run time but defaults
> to aRts.  This code couldn't be used in artsd, since well, one option
> sidesteps using aRts.

So we have forced duplication, then?  If we wanted GStreamer output in 
arts, your code would do no good?  And if aRts got the output, your code 
would bypass it?

> > Well, I can say right of the bat it's lacking filtering and support
> > for more than just the two encodings.  It also appears to lack the
> > network stream playback Noatun can be configured to do.
> Sure, there is a TODO list, and as much as these things can be made
> generic and shared, I'm all for it.  But I don't really care about
> having all of Noatun's features.  Noatun has features which are typical
> of that kind of app.  JuK has a lot of features that are typical of a
> jukebox.  If you want something like Noatun, well, use Noatun.  I'm not
> trying to replace Noatun, it's precisely what a lot of users are looking
> for.

The point is that everything you do in your app could be done with Noatun 
plugins, and would bring more functionality that way.

Look:  I'm not necessarily arguing against your app's inclusion in KDE 3.2.  
I favor a large, inclusive KDE.  I just question what value it would bring 
to the release that Noatun doesn't already provide.

- -- 
Neil Stevens - neil at qualityassistant.com
"Among the many misdeeds of the British rule in India, history will
look upon the act depriving a whole nation of arms as the blackest."
 -- Gandhi
Version: GnuPG v1.2.1 (GNU/Linux)


More information about the kde-multimedia mailing list