|  | | Re: Re: going wrong way
May 16 2006 on poll Your expectations for KDE4? |
1. KOffice is older than OpenOffice, but originally OpenOffice was StarOffice (made by some company then bought by Sun) and because it wasn't selling enough they released the open source version known as OpenOffice. So OpenOffice was developed for a long time as a closed source project and released as OSS much later so its had a lot of commercial support, while KOffice hasn't had much manpower till recently (it is catching up pretty fast to OOo, 2.0 should put them very close with MS document support being the last real big difference).
2. I was just using KHTML as an example (because its a similar situation to KOffice/OOo that comes up a lot). Also you can't really tell the developers what to do because most of them are volunteers and often are only interested in specific things (though the ones paid to work on KDE can be told what to do while being paid). Phonon and Solid should both lower the amount of bugs, and make things easier to debug, instead of having to debug N implementations of an media-engine with multiple backends you would only have to do it once, and instead of having to maintain how to manage hardware or find the state of the system in several different apps all of that would go into the Solid framework. Phonon and Solid shouldn't really be looked at as completely new projects, as much as optimizing already existing technologies making them MUCH easier to debug and maintain (both of which will also lower the barrier to making applications that take advantage of audio/video playback as well as find out/use information about the system like so Kopete doesn't keep trying to auto reconnect again and again to a remote server while you're not even connected to the Internet).
3. A lot of the 'rewrites' aren't done by actually KDE developers (and a lot of them become KDE developers BECAUSE of the rewrites).
4. The new Media Manager thing is pretty useful in some cases (and very easy to disable) and VERY helpful to newbies (if I put a Video-DVD into the computer I generally DO want it to be played in Kaffine), and if a passive popup tells me that the hardware I just plugged in was setup properly that doesn't bother me (long as its a PASSIVE popup), though just a Ding sound on success and a passive/active popup on failure would be better (though this isn't done yet at all, at least on Gentoo and SuSE).
5. I love KDE as well, and maybe I'm just more confident about KDE's future because I read pretty much every blog entry on PlanetKDE and every article on the Dot (a lot of the ones about Plasma are VERY interesting) |
| | | Re: Re: Re: pros and cons
May 16 2006 on poll Your expectations for KDE4? |
"i am not trying to be pessimist here but i think that what phonon is designed to do, is a really(!) difficult thing. afterall its supposed to channel all sorts of media (also video) through a rather large number of backends. this means that on both sides (input + output) it has to be 100% flexible.
-> a lot of code -> lots of possible bugs -> instability."
Kaffeine already does this and it works very well (despite originally being written just to use Xine), Amarok and Juk already does this (though for audio only) and they work pretty well.
"also making phonon compatible with so many backends will reduce their individual features."
Phonon isn't meant to expose all the features of every single backend, its supposed to provide the features 'most' people would need (i.e. simple playback mostly, look at the API documentation on EBN to see all that its currently planned to do), not to do very special case stuff like pro audio apps would need (those the Phonon devs recommend developing directly against a multimedia framework).
"will phonon be slim enough to not slow this down additionally?"
Phonon is a simple library, not a sound server, it wouldn't slow it down anymore than Kaffeine and Amarok and Juk are already slown down.
"talking about backends, why not pick one and trough focussing developement on that one provide an easier-to-maintain, slimmer and more stable interface for media-apps?"
There were GStreamer .6 bindings in KDE SVN, though when the next version of GStreamer came out they were broken horrible and it was taking so much effort to port the bindings they had to pretty much make all new bindings from scratch, with GStreamer .10 ABI compatibility with previous versions of GStreamer was broken (which would of broken kdelibs binary compatibility, and GStreamer would of had to of been forked to prevent that break if it had happened in the middle of the KDE 4 life cycle), and the GStreamer devs are talking about breaking compatibility again. To preserve ABI compatibility in KDELibs you would either need a project which will not break ABI compatibility (which GStreamer is not), or to abstract the interface away which you would the end up with a very Phonon like abstraction layer. Arts didn't have the ABI problem because its been unmaintained for a long time now.
"what about vlc(videolan)?"
What about Xine? What about GStreamer? What about Jack? What about NMM? What about QuickTime? What about DirectShow? What about aRts? What about ESD? What about /dev/null? What about future framework Y that comes out 1 week after KDE4 is released that blows all of those out of the water and nothing can even come close to comparing to and is universally agreed to be the best by every single person on earth? Phonon will allow for a multimedia framework to be chosen as the standard (gstreamer isn't the standard just because they want to be one), and when (if) that happens KDE can switch to using that as the default back end, and could even deprecate all the others if no one wants them. Phonon for one will prevent another aRts from happening to KDE. |
| | | Re: Re: Re: going wrong way
May 16 2006 on poll Your expectations for KDE4? |
A lot of times the 'rewrites' come out better than the 'original' (even though almost everything today can be considered a 'rewrite' of some older program). Should every one just stuck with XMMS, and never write Juk or Amarok? Many people love XMMS, though it can't do the things Amarok can, which a lot of people want (XMMS can't handle having music libraries which a lot of people need in order to handle having large amounts of music, I know my music can't be managed at all easily through just playlists). |
| | | Re: going wrong way
May 16 2006 on poll Your expectations for KDE4? |
Rewriting? You do realize that KOffice is older than OpenOffice? OOo is the new comer, not KOffice! Gimp and Krita aren't the same at all, Gimp is an image manipulation program (modify preexisting images/photos) and Krita is a paint program (ideal for image creation). Also Karbon14 may be older than Inkscape as well (at the very least it was started before inkscape was considered 'good enough'). Should KDE abandon KOffice just because some company releases another office suite as open source? KOffice is also MUCH ligher than OOo is, and the OOo people are having trouble doing pretty much any real work on it because the code base is such a horrible mess. Also if you say KDE should abandon KHTML for Gecko and Firefox and not 'rewrite' it, again I'll say that KHTML is older than Firefox, and gtkhtml is actually a port of an old version of khtml to GTK, Apple also considered KHTML to be a better choice than Gecko. Also Phonon isn't rewriting anything, nor is Solid. Both Phonon and Solid are abstraction layers, that way every KDE app doesn't have to have its own code to do hardware & audio for linux, bsd, OS-X, Windows, and others.
"i can't see why it should mean embracing the microsoftish "all users are hopeless morons and can't ever learn a thing" policy"
Isn't that the Gnome policy (at least the reducing functionality in the name of usability part)? Where has KDE reduced the functionality of anything that would warrant a statement like that? |
| | | Re: pros and cons
May 15 2006 on poll Your expectations for KDE4? |
"also whats the point of PHONON? i really think its going to be an artsdv2, with all its flaws, because the concept itself is flawed. why can i not just set the media-engine per-application? it works well now doesnt it? so if kaffeine and amarok and juk and so on use gstreamer now, why would i want to squeeze another programming layer inbetween? its no benefit, just another source of bugs!"
What Phonon will do is pretty much move that abstraction code out of those applications and put it in a common kde-wide library. This will REMOVE duplicated effort, and make it much easier to do common audio related things (look at the sample of juk's aRts implementation vs Phonon implementation, the Phonon one is MUCH simpler). Also it will most likely be possible to override which engine to use on a per-application basis (though whether or not that application exposing the choice to the end user depends on the app devs).
Phonon also means that when GStreamer breaks ABI compatibility (which they did with 0.10, and are talking about doing again), KDE doesn't have to fork GStreamer and end up with another aRts. Also for the people like me that have NEVER had gstreamer work for them (IMHO gstreamer is worse than aRts, at least aRts will play sounds on my laptop, and works perfectly fine on my desktop) they can chose Xine.
In short Phonon means less duplicated effort, the ability to manage audio of many applications at once (i.e. sound categories will allow a volume manager program to adjust the volume of system notifications when you're talking on a VoIP program, or combined with Solid will switch the VoIP program to use a headset you just plugged in depending on your settings). I like Phonon because I will be able to pretty much replace aRts with Xine on my laptop and desktop. |
| |
Search people
Current visitors
New users
Birthdays
Most active users
Back
|
|
| | |
