Dan Armak posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 02 Jul 2005 19:52:42 +0300:
> On Saturday 02 July 2005 18:47, Duncan wrote: >> Dan Armak posted <[EMAIL PROTECTED]>, 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
