Dan Armak posted <200507021952.48489.danarmak@gentoo.org>, excerpted
below, on Sat, 02 Jul 2005 19:52:42 +0300:
> On Saturday 02 July 2005 18:47, Duncan wrote:
>> Dan Armak posted <200507021533.38731.danarmak@gentoo.org>, excerpted
>> below, on Sat, 02 Jul 2005 15:33:34 +0300:
>> > At least arts is going away with kde 3.x :-)
>>
>> I read the rumors on that about a year ago, [but have] heard
>> essentially /nothing/ on it since then.
>
> I'm hardly a reliable source on this, I can only repeat what I've seen
> on the kde-devel and kde-core-devel mailing lists
That's more than I'd seen recently, so good enough for me! =8^)
>> Back then, there wasn't even a solid proposal as to what would replace
>> ARTS' various functions. The best solution seemed to be the
>> desktop.org common solution, only nobody knew [what form it would
>> ultimately take or when]. gstreamer and other possible partial
>> solutions came up as well.
>
> I say aRts is going away because it's nearly or entirely unmaintained
> for a long time now and has been declared dead many times in many
> forums. AFAIK it's not been decided yet what to replace it with beyond
> what you already wrote here.
Declared dead, yes, but it's still walking among us...
> I know there's a new thingy called kdemm, but it's just a framework
> IIRC; it will still need a sound daemon doing mixing and output behind
> the scenes. The daemon is what hasn't been decided on yet, but maybe
> kdemm will support a choice of several (I've no idea if that'll happen).
Actually, that last idea, supporting several, seems to ring a bell. I'd
seen a framework mentioned as well, but nobody knew what it would look
like originally. However, putting the pieces (the others are little more
than side mention hints, but they fit nicely into the above, so I expect
the picture I'm getting is as decently accurate as anyone can see at this
point) together...
I now believe kdemm is going to be as you mention the unified KDE part of
the framework. The idea is to have a common API for KDE objects, with
driver plugins for the various sound driver elements and platforms. I
don't believe anything, therefore, is slated to directly replace the lower
level functionality of ARTS (and indeed, from what I remember reading, the
opinion is that one of the biggest problems with ARTS was it tried to be
too much to too many, vastly complicating the situation, making
maintenance a nightmare, and making it not really ideally good at
anything). Rather, the general API kdemm framework is intended to keep
things at a fairly high level, with individual output bridge-plugins for
ALSA, JACK, OSS, gstreamer, etc, intended to function as middleware
drivers, interfacing between kdemm and the various lower level platform
drivers, whatever they may be.
Keep in mind that QT4 now has a GPL version to run on MS platforms as
well, and that KDE4 is being designed with an MSWindows port in mind too.
The above kdemm framework idea, with the general kdemm framework remaining
relatively high level, and output bridge-plugins filling the gap between
it and the various platform sound-hardware drivers makes even more sense
with this in mind, as kdemm as a KDE framework can then function on
MSWindows with few to no changes at all, only a recompile with a suitable
system compiler, and with an appropriate bridge-plugin interfacing to the
MSWindows sound system as just one of a list of similar plugins filling
the same functionality on the more traditional for KDE Unix platforms.
As I said, that little bit you mentioned was just enough to start putting
the pieces together! <g> It makes perfect sense and all the pieces fit,
tho, now that you provided the missing pieces. =8^)
>> If there are any informative URLs[...] The latest release plan I see is
>> still for 3.4.0 and dated from late last year!
>
> I guess that page will be updated sometime before the 3.5 release cycle
> actually starts with alpha1...
>
> There's a 3.5 feature plan at
> http://developer.kde.org/development-versions/kde-3.5-features.html, and
> a recent short m/l thread about the release plan starts at
> http://lists.kde.org/?l=kde-core-devel&m=111934060916267&w=2, which
> isn't conclusive but is nearly so.
PERFECT! Just what I wanted! Thanks.
So... from reading, it looks like they are targeting KDE 3.5 feature
freeze either just before aKademy (late Aug.), with a release to follow
likely b4 Xmas vacation, or intending to leave the schedule a bit soft for
now, freezing maybe a bit later, late Q3 or into Q4, when development
has naturally seemed to slow down due to focusing on 4.0, with the
3.5 release then in the spring, leaving a smaller gap between it and 4.0.
4.0 then would be a year to a year and a half out (someone said two, but
it was pointed out a year and a half is about as far out as it can go
before it starts screwing things up, a la Debian's release that seemed it
would never come, people deserting it, etc), later than June 2006, with a
mention of KDE's 10th birthday, October-ish, 2006, as a very nice target.
I expect that 10th birthday thing to be symbolic enough they'll probably
shoot for that. There's a /lot/ of work to do by then, that /must/ be
KDE4, it can't go in KDE3 (kdemm is one example, moving off of ARTS isn't
something they want to do in the 3.x major release series, for good
reason, IMO), so that's going to be tough to hit, but if it slipped to
Xmas 2006, it's still hit the year and a half thing pretty well, and if
3.5 is released spring 2006, that wouldn't be /too/ bad.
Of course, the 3.5 targeted features list looks interesting, too, but I'm
not going to attempt commentary on that, here. <g>
So, yes, /exactly/ what I wanted. That gives me a nice roadmap of what's
ahead with KDE and when, thru 4.0, subject to revision, of course, but
/exactly/ what I was looking for, and probably informative to others on
the group/list as well. Thanks again!
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html --
gentoo-dev@gentoo.org mailing list