Removing aRts

[Thiago Macieira]

Sorry for cross-posting again.

Matthias Kretz wrote:
>On Thursday 16 February 2006 18:48, Thiago Macieira wrote:
>> So, can we remove aRts from trunk/KDE ? I think --without-arts is
>> already the default anyways.
>
>I see no reason for keeping arts in trunk/KDE, it might be usefull to
> move it to trunk/ instead, but since it's probably only going to bitrot
> there we can remove it now.

Ok, so let's do it like this:

1) arts gets moved from trunk/KDE to trunk/kdesupport
2) someone steps up as a maintainer, assigns the Bugzilla entries to 
himself and starts closing the bugs there (note I didn't say "fix" 
because I know most of them are duplicates and there are wishlists too)

If #2 doesn't happen in a certain timeframe, we'll remove it from 
trunk/kdesupport. If someone wants to resurrect it, all they'd need to do 
is #2.

This is not talking about trunk/KDE/kdelibs/arts or any kind of aRts 
backend for Phonon. The way I see it, aRts 1.5 is good enough for most 
people and Phonon might be able to support that version (it needs a new 
libqtmcop, right?)

This is also not talking about branches/arts/1.5. That still needs to be 
supported, somehow.

>kdelibs has a subdir called arts, in there is artsmessage, the tool aRts
> uses to notify the user graphically, and some KDE APIs for simplifying
> aRts usage. That can also be removed from kdelibs, IMHO.

I hadn't thought of kdelibs/arts yet, but if this is kde-multimedia's 
position, we can do it too.

Before anyone complains about losing the code, please remember that 
restoring deleted files in Subversion is easy.

>As I'd like to create an aRts backend for Phonon I will probably
> reactivate some of that code - but in a different module. This, btw, is
> another question I have: where should Phonon backends go?
> trunk/KDE/kdemultimedia/? And when the decision for a default backend
> is made, that one backend is moved to kdelibs, or kdebase?

Well, the way I understand it, sound support is a key feature that needs 
to be in the KDE core libraries. The level of support and whether it will 
also include other media, you MM guys are in a much better position to 
answer. This means that someone building kdelibs but not kdemultimedia 
needs to have at least one backend.

Obviously the more advanced MM stuff should be in a separate library or in 
application code.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

2. Tó cennan his weorc gearu, ymbe se circolwyrde, wearð se cægbord and se 
leohtspeccabord, and þa mýs cómon lator. On þone dæg, he hine reste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060217/613a7a1e/attachment.sig>