JuK -> KDE CVS

[Scott Wheeler]

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

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

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

This was a direct responce to several people asking for this since for music 
playback I've always personally been fine with aRts.  And all of this code is 
pretty minimal, maybe 500 lines for all three classes total.  Also, this is 
an interesting proof-of-concept for GStreamer in a KDE app.  And if you don't 
like it, use aRts.  :-)  Again, that's still the default; none of the 
packages yet include the GStreamer support, and, that's what I use.  :-)

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

Cheers,

-Scott

-- 
The three chief virtues of a programmer are: laziness, impatience and hubris.
--Larry Wall