aRts in trunk

[Mark Constable]

On Saturday 30 July 2005 03:47, Charles Samuels wrote:
> > Given that we're not planning on supporting aRts in 4.0 and that I don't 
> > expect any further development on aRts in trunk, I personally don't see a 
> > reason to keep it there.
> 
> And what if there is?

Far out weighed by the greater need to get rid of it.

> Advantages to keeping it in trunk:
> - I can easily make fixes to it if I need.

Fixes for arts... wow, that'd a first for.. I can't remember how long.

> - I can use it and it'll be easy for testers to as well

All that will achieve is to prolong an already over due death.

> Disadvantages:
> - You don't have to look at its ugly face.

No but whoever has to look at the code will think otherwise.

> No, I think you just don't like aRts and want to see it go away, even 
> though, as I've said, we haven't decided on an alternative, because the 
> alternatives suck too.

The alternatives (gstreamer, xinelib) suck less than arts.

> Of course, it seems, you've already made up your mind, so whatever I say 
> won't matter.

I, for one, seriously hope it gets removed asap. The sooner it's
gone the sooner we'll have an official replacement and that will
be the appropriate code to put any effort into.

> -Charles, who's getting fed up with politics

Well fix arts and step up to maintain it.

We need a kjackd... which could be a tweaked qjackctl.

Jack can sit on top of Portaudio for non-linux KDE systems.

--markc