Weekly Edition
Return to the Development page
| |||||||||||||
|
| |||||||||||||
KDE 4.1 released
The KDE 4.1 release is
available. "KDE 4.1 is the first KDE4 release to contain the
Personal Information Management suite KDE-PIM with its E-Mail client KMail,
the planner KOrganizer, Akregator, the RSS feed reader, KNode, the
newsgroup reader and many more components integrated into the Kontact
shell. Furthermore, the new desktop shell Plasma, introduced in KDE 4.0,
has matured to the point where it can replace the KDE 3 shell for most
casual users." See the announcement for details and lots of
screenshots.
(Log in to post comments)
KDE 4.1 released Posted Jul 29, 2008 17:43 UTC (Tue) by Sutoka (guest, #43890) [Link] Theres also a 'Is KDE 4.1 for you?' (http://techbase.kde.org/Schedules/Is_KDE_4.1_for_you%3F) page on Techbase (linked from the article on the Dot) that lists some of the issues with the current release (the issue with the nVidia drivers, the missing applications, and Plasma from a quick glance). All-in-all it's quite a large jump in maturity over 4.0, especially Plasma.
KDE 4.1 released Posted Jul 29, 2008 18:04 UTC (Tue) by erwbgy (subscriber, #4104) [Link] Yes, they are working hard to set the correct expectations with this release. The annoucement also says: While KDE 4.1 aims at being the first release suitable for early adopting users, some features you are used to in KDE 3.5 are not implemented yet. The KDE team is working on those and strives to make them available in one of the next releases. While there is no guarantee that every single feature from KDE 3.5 will be implemented, KDE 4.1 already provides a powerful and feature-rich working environment. Note that some options in the UI have moved to a place in the context of the data they manipulate, so make sure you have a closer look before you report anything missing in action. KDE 4.1 is a huge step forward in the KDE4 series and hopefully sets the pace for future development. KDE 4.2 can be expected in January 2009.
Phonon Posted Jul 29, 2008 18:29 UTC (Tue) by togga (subscriber, #53103) [Link] I've read many explanations over the years but found none that I can understand. Why introduce the Phonon overhead instead of using or improving the Gstreamer framework which is adopted by freedesktop.org?
Phonon Posted Jul 29, 2008 18:54 UTC (Tue) by theICEBear (subscriber, #23193) [Link] There is a set of arguments here from the KDE people: 1) GStreamer was not API stable enough for the KDE project's liking and as they want be API stable for the entire 4.x series of KDE they feared having to keep an updated version around thus possibly missing a lot of new features in what is a rapidly developing and diverse field especially on Linux. 2) They wanted to be able to code KDE4 applications (the ones that do not need highly advanced features such as video editing and the like) on platforms such as FreeBSD, Mac OS X and Windows (KDE have several very active alternative platforms such as Mac OS X, Windows, the BSDs and Solaris) and they wanted their API to abstract those platforms away from the applications. There were more and deeper explanations than this, but that is what I remember from the original articles on KDE4.
Phonon Posted Jul 29, 2008 19:21 UTC (Tue) by togga (subscriber, #53103) [Link] Thank you for the explanation! 1) What they're saying here is that GStreamer API is a mess such that a completely new API will be more stable in a given timeframe. 2)This can be abstracted inside GStreamer. I believe GStreamer has been ported to all platforms you mention. I can buy the first argumentif it looked really hopeless even if I think a collaboration effort is much more productive.
Phonon Posted Jul 29, 2008 19:33 UTC (Tue) by sbdep (subscriber, #13282) [Link] Now reevaluate your view in the context of 1.5 years ago when the various kde apps that did support gstreamer directly were going through all sorts of pain dealing with the api/abi changes from gstreamer 0.8 to 0.10. Along with everyone else using gstreamer for that matter. The KDE developers goal was to provide a source/binary interface that would be stable for application developers to use for the life of KDE4, while still being able to change out the underlying system as the gstreamer changes and other audio system changes that are bound to happen over the next 5-10 years.
Phonon Posted Jul 29, 2008 19:35 UTC (Tue) by sbdep (subscriber, #13282) [Link] Whether or not they are right or not, is of course a matter that will be decided in the future when we can look back and see whether or not there were other underlying changes that the intermediate Phonon layer wrapped up for the application side developers.
Phonon Posted Jul 29, 2008 19:43 UTC (Tue) by nix (subscriber, #2304) [Link] The gstreamer API is quite complex. Phonon is *simple*. Think of it as being more like a C++ variant on Lennart's libsydney than like gstreamer: its job is to make playing simple sounds easy, not to expose all the wizardly magic that gstreamer can do. Actual multimedia apps like Amarok will talk directly to gstreamer et al, rather than going through phonon.
Phonon Posted Jul 29, 2008 23:43 UTC (Tue) by togga (subscriber, #53103) [Link] Simplicity is in the eye of the beholder though. I played around with the GStreamer API and cannot really associate the wording "quite complex" to this: import gst player = gst.parse_launch(r"playbin uri=http://www.vorbis.com/music/Epoq-Lepidoptera.ogg") player.set_state(gst.STATE_PLAYING) You probably have a valid point here. I'll try the Phonon API later on [for playing the same URL] and compare to the above to see what you mean with "Phonon is *simple*".
Phonon Posted Jul 30, 2008 1:10 UTC (Wed) by nix (subscriber, #2304) [Link] Perhaps 'complex' isn't the word. 'Large and overwhelming to the new user' is perhaps better. (This isn't to damn it, it's true of all large APIs.) A tiny API that only provides a few simple things won't be as capable, but isn't going to scare anyone off either. (This is slightly marginal though, as anyone using KDE has had to learn gigantic APIs already and one more isn't going to scare them. The fact that Phonon is a KDEish API and that it's cross-platform portable, as ohters have pointed out, is probably more significant.)
Phonon Posted Jul 30, 2008 9:44 UTC (Wed) by togga (subscriber, #53103) [Link] I've now briefly looked at the Phonon API and it appears to me that it's only a subset of GStreamer API [high-level components] with some added widgets. Both use the same basic concept of linking objects together - Phonon calls it "Path" and GStreamer calls it "Pipe". >> KDEish API I think you nailed it here. The API is rather redundant to GStreamer - both in concept, simplicity and portability. It should've been easy to adapt GStreamer instead of using Phonon. It's all about the K's and the Q's. I think this is a pity since the Phonon abstraction layer will rather scatter resources than focus on producing one top-class framework. >> Large and overwhelming to the new user Sure, GStreamer has a more complex model, but it's rather easy to understand - and probably worth it once you want to do a lower-level operation. What will be interesting is - if Phonon API turnes up not enough for some applications - will the Applications 1. move to GStreamer 2. start requesting and implementing features in the Phonon API 3. dig up backend components and perform low-level operations My guess is that the shortest path (3) will be chosen until the application is so messy that it either dies a natural death or take a big leap to (1) - unless community-gods are with you and provide you with (2) which is the case where Phonon converges to a K version of Gstreamer. >> cross-platform portable I think that implementing a backend for Phonon to another platform should be no less complicated than implementing a handful of low-level components for GStreamer.
Phonon Posted Jul 30, 2008 15:26 UTC (Wed) by dkite (guest, #4577) [Link] It's quite simple. An application written today for KDE 4.0, which has a button that produces a 'bleep' sound, will work without recompile or code changes in KDE 4.6.11. That is the goal. Usual caveats apply, no Gcc abi changes, all else being equal, etc. Gnome has a different goal and structure, of incremental changes that all applications adapt to over the life of a series. GStreamer changes api/abi, the whole project follows. KDE has a goal of binary compatibility. I don't think GStreamer has or is willing to guarantee such api/abi stability for the next, what, 5 years. So, it's either roll your own, or abstract the lower level drivers. GStreamer can change as it will, phonon will be maintained to work with the changing drivers, and the application button will make the 'bleep' sound. Derek
Phonon Posted Jul 31, 2008 0:00 UTC (Thu) by togga (subscriber, #53103) [Link] Finally, with enough eyeballs, all confusion are shallow. Thank you for this explanation! There was a lot of confusing arguments floating around.
Phonon Posted Jul 30, 2008 17:20 UTC (Wed) by Sutoka (guest, #43890) [Link] >It's all about the K's and the Q's. I think this is a pity >since the Phonon abstraction layer will rather scatter >resources than focus on producing one top-class framework. Actually before Phonon existed there were GStreamer bindings in KDE's SVN (intended to be used for KDE4). Except then the GStreamer API was changed and the bindings broke. By the time KDE 4.0 was released, the API was changed yet-again. >Sure, GStreamer has a more complex model, but it's rather >easy to understand - and probably worth it once you want >to do a lower-level operation. The nice thing about Phonon is the fact that not everyone wants or needs to do low level operations. >What will be interesting is - if Phonon API turnes up not >enough for some applications - will the Applications Phonon isn't *supposed* to be enough for all applications. An advanced audio editing application is *not* the intended audiance for Phonon. Phonon is meant for the higher level applications like exist in KDE's Edutainment module and Amarok/Kaffeine (which had already been maintaining their own API abstraction layers internally).
Phonon Posted Jul 30, 2008 19:35 UTC (Wed) by k8to (subscriber, #15413) [Link] > I think you nailed it here. The API is rather redundant to GStreamer - both in concept, > simplicity and portability. It should've been easy to adapt GStreamer instead of using Phonon. You are missing the forest sir. Phonon *is* adapting GStreamer. Phonon's reduced exposure of functionality is a feature. By limiting the functionality provided to the set that "desktop appplications" are likely to use, the effort required to maintain an ABI-compatable layer on all shipping KDE platforms is remarkably reduced. It may be that GStreamer would do all that work for KDE, and thus using GStreamer would be less work, but those ARE NOT GSTREAMER'S GOALS, and when the paths diverge, KDE would not have their goals met. It's that simple.
Phonon Posted Jul 30, 2008 20:18 UTC (Wed) by boudewijn (subscriber, #14185) [Link] When will people -- especially people who subscribe to LWN and thus may be suspected of a modicum of clued-inness -- stop thinking of free software developers as "resources" that can be wasted, scattered or focussed on something. Free software development simply does _not_ work that way. Really, it doesn't.
Phonon Posted Jul 30, 2008 23:56 UTC (Wed) by togga (subscriber, #53103) [Link] Sure it does. If they didn't have to do Phonon, then they should do something else at that time. Maybe contribute to GStreamer, maybe not coding at all or maybe contribute to the community in other ways. It works the same way, except the decision is in the head of the individuals. But with enough individuals and statistics...
Phonon Posted Jul 31, 2008 1:55 UTC (Thu) by dkite (guest, #4577) [Link] Ok, let's imagine some reality. In kde-edu, there are 24 (ish) applications, many of them make noise of some sort. Not music players, editors or anything that need very high level of control over the hardware. They make noise, music in games, voice, etc. Some record. If they wrote to Gstreamer, right now, they would all do the calls that a comment above quoted. Say, at one point in the next 5 years, GStreamer changes it's api. What would happen is of the 24 apps that use sound, they all would need to write something like: if (gstreamer version x) this api call if (gstreamer version y) that api call KDE likes in situations like that to create a library so that the same code complexity doesn't have to be repeated in every application. So you see, phonon is a solution to a problem that will exist. And since the abstraction layer (kde is full of them) already exists, other problems can be addressed, such as platform abstraction, and abi stability. The idea that someone writing KLatin is somehow stealing development resources from GStreamer if they want an abstract noise making api that is api/abi stable for the life of the series is absurd. Derek
Phonon Posted Jul 31, 2008 10:51 UTC (Thu) by togga (subscriber, #53103) [Link] Sorry to have confused you, this little sub-thread was a side-step and not about Phonon itself, it only used Phonon as an example in a misleading way. Yes. It good to see that this thread has converged to a valid explanation. I also hope that GStreamer will be _used_ default by the distros out there. With the pluggable backends, he KDE team went one step further than just make a new API. So the decision is still not to embrace GStreamer and leave it out in the cold. For example: Instead of using GStreamer for Windows [which should be really easy to do wrt how well Phonon/GStreamer models match], they have implemented a new back-end for Windows using the proprietary dShow API. These are the active choices KDE has made that brings the original concern [scattered multimedia focus] up to the table again. Now, not only the GStreamer API is in question but also its functionality. And a short path of not implementing that fuctionality in GStreamer [for example a MPlayer plugin]. To summarize: KDE had valid reasons for making a new Phonon API, but they have not embraced GStreamer.
Phonon Posted Jul 30, 2008 1:52 UTC (Wed) by aseigo (guest, #18394) [Link] Amarok, Dragon Player, Kaffeine and most others all use Phonon. it's not so simplistic as to be a toy; in fact, being able to service apps like Amarok and Kaffeine (specifically) was one of the concerns taken into the design phase.
Phonon Posted Jul 30, 2008 5:21 UTC (Wed) by nix (subscriber, #2304) [Link] Hm. Wow. OK, it's more capable than I thought. I'll have to look at it again. :)
Phonon Posted Jul 30, 2008 7:01 UTC (Wed) by ceplm (subscriber, #41334) [Link] Concerning 1) -- you have to understand the context of the decision to create Phonon API (note, I am now very happy GStreamer/Gnome user, but used to use KDE in the time when the decision was made). KDE sound applications were then in the middle of the mess of failing arts and GStreamer was then in the middle of transition from 0.8 to 0.10 (which frankly either hasn't ended yet or it ended not so long time ago). I don't think it's a wonder, that they decided on yet one more safeguard against possible failing of GStreamer. You know, burned once ... burned twice.
Phonon Posted Jul 30, 2008 7:35 UTC (Wed) by erwbgy (subscriber, #4104) [Link] Yes, that's the key point: they didn't want a repeat of the problems they had with arts, which was essentially unmaintained for a long time (in KDE terms) and could not be easily adapted to their changing needs. Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem. - David Wheeler (1927 - 2004) In a few years we will see what the next problem is. At least it will be different :-)
Phonon Posted Jul 29, 2008 18:56 UTC (Tue) by guinan (subscriber, #4644) [Link] Probably because GStreamer is based on GObject. See "THE BAD" here for example: http://www.kdedevelopers.org/node/426.
Phonon Posted Jul 29, 2008 19:29 UTC (Tue) by togga (subscriber, #53103) [Link] Thank you. This looks to me like the real issue. Maybe if GStreamer was called "XStreamer" instead and were not based on GObject, we might have had a common media component between all major desktops.
Phonon Posted Jul 29, 2008 21:19 UTC (Tue) by aleXXX (subscriber, #2742) [Link] No, no, no, this is really not the case. So, gstreamer is the one multimedia framework which will be the best and stable etc. for the years to come ? What about nmm ? Helix ? Xine ? What to do on OSX which has its own (Quicktime ?) API ? Same for Windows (DirectSound ?) ? Phonon is really a layer which -makes the backend replacable -can offer a stable ABI/API while the backends change -makes common things easier, especially for Qt/KDE developers Alex
Phonon Posted Jul 29, 2008 19:17 UTC (Tue) by rfunk (subscriber, #4054) [Link] Aaron Seigo puts it like this:specifically, the day that gstreamer or any other media engine provides:
Phonon Posted Jul 29, 2008 21:04 UTC (Tue) by robert_s (subscriber, #42402) [Link] Phonon is intended to be a simpler abstraction for more trivial uses.
Phonon Posted Jul 29, 2008 21:22 UTC (Tue) by aleXXX (subscriber, #2742) [Link] GStreamer isn't on the fd.o standards page: http://www.freedesktop.org/wiki/Standards It's on the fd.o software page, which says: "Software hosted on or related to freedesktop.org Some software has made its way here to live. None of this is "endorsed" by anyone or implied to be standard software, remember that freedesktop.org is a collaboration forum, so anyone is encouraged to host stuff here if it's on-topic." So, gstreamer is just hosted on fd.o, it is not "adopted" or a standard or something like this. Alex
KDE 4.1 released Posted Jul 29, 2008 19:14 UTC (Tue) by N0NB (guest, #3407) [Link] It's good to see progress from the KDE4 project. As one happy with KDE 3.5.9, I'm looking forward to KDE4, but not likely to jump much before KDE 4.3 unless 4.2 is "there". Fortunately, there will be plenty of opportunity to check it out before I switch for good. Good show KDE devs!
Live image? Posted Jul 29, 2008 19:54 UTC (Tue) by leoc (subscriber, #39773) [Link] Anyone know where to find a bootable live image to try it out?
Live image? Posted Jul 29, 2008 20:59 UTC (Tue) by leoc (subscriber, #39773) [Link] Oh never mind, I found it.
|
|
||||||||||||