In this week's KDE CVS-Digest:
KDE integrates Mono with C# bindings.
A PHP debugger integrated into Quanta.
Work continues on eGroupware / Kontact integration.
Kopete rewrites the Jabber plugin.
Plus, a new tool for monitoring application usage.
Dot Categories:
Comments
NMM can't be hosted on freedesktop (without a fork) because it's a research project funded by a university, and they want control of it.
The hosting issue shouldn't matter afaics, there already were and still are quite some projects represented on fd.o which don't make use of its CVS and bug tracker.
Seems that they use sourceforge CVS for development:
http://sourceforge.net/projects/nmm
Since it is licensed under the GPL/LGPL I very much doubt that the university can totally control the project if the developers perhaps want to get involved with freedesktop. I don't see any problems.
How do these sound systems compare? MAS vs NMM vs JACK vs GSTREAMER etc.?
Why is Gstreamer not the best choice in all cases? What's bad about Glib and Gobject, does it produce unreadable code?
Did GNOME already adopt Gstreamer? Which sound architecture is KDE leaning towards?
JACK is simply an audio server, not a multimedia framework. All it allows you to do is play more than one sound at a time and have them all mixed together. MAS, GStreamer, and NMM all appear to be comparable graph-based multimedia frameworks. They allow you to connect items together in a graph structure, like: file source -> MP3 file format reader -> MP3 data to raw audio converter -> raw sound card output. MAS is concerned more with X windows integration. GStreamer tries to be fast and useful in general for more than just media playback (think nonlinear video editing, etc). NMM appears to be focusing on synchronized playback on multiple networked devices and handoff between devices (play music on your PDA while you jog and hand it over to the stereo when you get home).
GStreamer seems to me to be the project most focused on the needs of the desktop computer user. NMM's network tricks look impressive at first glance, but I question whether all that network stuff needs to be built into the multimedia framework. It can be done more easily and more sensibly by plugins or at the application level IMHO, and that way only applications that need it (which are pretty few after all) have to worry about it. I don't see why the same things that NMM is doing couldn't be done with GStreamer. As for MAS, I'm not sure how much active development is going on in that project. I think GStreamer is a more active project. I'm not sure how the technical capabilities of MAS and GStreamer stack up, but I can't imagine that GStreamer is any worse than MAS.
Glib and Gobject are projects that are not technically part of the GNOME project, but they have strong ties to GNOME. There is some reluctance in the KDE community to depend on GNOME's underlying C libraries. As for code readability, that is a matter of taste, but C++ bindings to GStreamer would eliminate that complaint, and they would almost certainly be made before KDE adopted GStreamer.
It has been announced that GStreamer will be a standard part of the next GNOME release. KDE is not leaning toward any particular multimedia architecture at this time, though almost everyone agrees that aRts is not going to be it. The new multimedia architecture will be decided on at some point before KDE 4 is released.
The network stuff isnt "built-in" in NMM, it is a plugin just like any other. Imagine the play graph, and just add a network-plugin: Source->Decoder->Network->Audio-server.
Well what's so special about that then? A network plugin for GStreamer would be easy to make, if someone wanted to make one (they don't though, because there's hardly any practical use for such a thing right now). I was under the impression that NMM involved the network at a more fundamental level.
> As for code readability, that is a matter of taste, but C++ bindings to GStreamer would eliminate that complaint,
> and they would almost certainly be made before KDE adopted GStreamer.
KDE wrapper for GStreamer:
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdenonbeta/gst
For people interested in comparing NMM & Gstreamer, please note that the amaroK developpers are currently trying NMM. Let's wait for their feedback since they have already tried Gstreamer .
See the following threads.
http://lists.kde.org/?l=kde-multimedia&m=107763526429514&w=2
http://lists.kde.org/?l=kde-multimedia&m=107868076101110&w=2
Find also some pros & cons relatively to NMM & Gstreamer here.
http://lists.kde.org/?l=kde-multimedia&m=107757209614312&w=2
Other remarks:
1)Relative to NMM being a research project, if I remenber correctly, it's exactly what was Gstreamer at the beginning.
2) Relative to NMM being "mature", one should look at their "Multimedia box".
http://graphics.cs.uni-sb.de/NMM/Status/MMBox/index.html.
Regards
Phil Ozen
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/~checkout~/kdebase/kcontrol/TODO
Good to see they're working on the KControl reorganisation.
Is there any move to switch over to SVN for version control? It sounds like a natural progression from CVS (although I couldn't find any info whether there is a way to upgrade a current CVS repository).
Subversion is still too imature for us to adopt, though it's likely we will at some point in the future. It has many features we'd like - especially the better support for tags, branches and versioned directory handling. One of the major things lacking is support for it in the surrounding tools, though i'm told recent versions of viewcvs support it (and work on support in cervisia is started).
Should you rather go with a GPL'ed version control system like GNU's Arch ?
That IMO should be supported by kdevelop also at some point...
Arch has the wrong model for KDE - we want a central repository.
Wow, a brand new set of KDE#/Qt# bindings? Richard, you rock!
I don't know how hard it was to do, but it sure sounds like a testament to all the foundation work you did with libsmoke.
Do you have any examples or screenshots of running examples? :)
I've been playing some with Mono for the last week. I think "managed languages" is a really interesting development for desktop programming, and while C++ with Qt may be very nice, C++ is nonetheless a barrier for many would-be KDE coders. So I was sad to see that more than a whole year had gone since the last release of the Qt# bindings. Today I decide to check again, and first I find that Qt# 0.7.1 was released just yesterday, and second I find Richard's smoke bindings. Excellent, thanks!
Yer great, and I'm glad someone is still hacking on this.
Let's hope that people can start seeing beyond the hype of Mono and .NET.
Hi Navindra - thanks!
I've done what it says in the commit, but perhaps that isn't obvious. All the current generated code does is to funnel all the Qt/KDE method calls to a single C# method, SmokeInvocation.Invoke(). At present it looks like this:
public override IMessage Invoke(IMessage myMessage) {
Console.WriteLine("MyProxy 'Invoke method' Called...");
if (myMessage is IMethodCallMessage) {
Console.WriteLine("IMethodCallMessage");
}
if (myMessage is IMethodReturnMessage) {
Console.WriteLine("IMethodReturnMessage");
}
if (myMessage is IConstructionCallMessage) {
}
}
Notice that it doesn't do anything other than print debug messages! So the next step is too look up the corresponding method in the Smoke library and call it. That should be about another week or two. But it should then move quite quickly from just running 'hello world' to being pretty complete in a month or two.
-- Richard
What didn't make it into the digest:
revision 1.798
date: 2004/03/17 19:23:27; author: eschepers; state: Exp; lines: +381 -20
new feature: composing HTML messages
Although I generally find html messages disgusting, I understand that kmail does somehow *have* to support this. Out of curiosity I wrote two messages to myself using html and it worked *very* well. Good job! Not that I would ever use the feature. Actually, my mail system marks every incoming html message as spam right away -- very few false positives so far. ;-)
Well. I actually reject HTML at the server. 99.5% of spam never reaches my inbox.
it's cool that kdepim and egroupware are working together but I'm a phpgroupware user so I was just wondering whether I should switch or not...
http://members.shaw.ca/dkite/dec52003.html
phpgroupware support was added at the same time as egroupware support.
Derek
- Make aRts work with dmix. Two important changes:
1. Dmix uses read-events to signify write-events, so we need to autodetect what kind of crack ALSA is smoking today.
BTW: I just installed KDE 3.2.1 on Xandros 2 Business Edition! It rocks! Much better than even their customized KDE imo. =)
Check it out: http://graphics.cs.uni-sb.de/pipermail/nmm-dev/2002-November/000024.html
Of particular note:
"Of course, we would like to see cooperation with KDE people, actually we
wanted to start to develop a media player for KDE, but we changed our
plans because we currently do not have enough 'manpower'. That is why we
focus on the development of the Multimedia-Box. (Of course, the
multimedia-box is in some sense also a 'player'.)"
Seems like these people like KDE and would be pleased and cooperative if KDE chose to use it. =) One plus for NMM. Is there any chance GNOME would adopt NMM?
Really, the main thing going for Gsreamer is a unified architecture between KDE and GNOME.
BTW: Please tell me the difference between NMM and Gstreamer.
> BTW: Please tell me the difference between NMM and Gstreamer.
Good things about gstreamer:
Relatively mature (1.0 release upcoming before KDE 4.0)
developers who want to cooperate with KDE
gnome will use it
modular architecture + lots of modules
Bad things about gsteamer:
not C++
uses glib+gobject
not network transparent
Good things about NMM:
C++
Network transparent
developers who want to cooperate with KDE
modular architecture
Bad things about NMM:
not terribly mature, compilation often breaks ATM
research project (no idea if developers will continue after graduation, and many experimental features not suitable for desktops like KDE and GNOME)
For a comparison between NMM & Gstreamer, please note that the amaroK developpers are currently trying NMM. Let's wait for their feedback since they have already tried Gstreamer .
See the following threads.
http://lists.kde.org/?l=kde-multimedia&m=107763526429514&w=2
http://lists.kde.org/?l=kde-multimedia&m=107868076101110&w=2
Find also some pros & cons relatively to NMM & Gstreamer here.
http://lists.kde.org/?l=kde-multimedia&m=107757209614312&w=2
Regards
Phil Ozen
Some of the things you say are very, well, "flamey".
GStreamer can be network transparent if you want it to. Its a matter of ju\\making a plugin. GStreamer can already play files on a webpage, a network source etc.
What is wrong with being coded in C++?
What is wrong with GObject and Glib?
GStreamer has C++ bindings in KDE CVS i am sure. Juk uses them. glib and gobject are not huge. It is not a big issue. Why reinvent the wheel?
Apparently, C does not impose an API on you like C++, so it makes C a good choice for a library like GStreamer which is abstracted anyway.
Another good thing about GStreamer is that it is very small and can fit on a handheld. It has already done this. It is useful in embedded applications. It also helps to use the same framework on different devices.
"Some of the things you say are very, well, "flamey"."
Mmm. Well.
"GStreamer can be network transparent if you want it to. Its a matter of ju\\making a plugin."
So it doesn't do network transparent stuff, nor is it fundamentally designed for it.
"GStreamer has C++ bindings in KDE CVS i am sure."
Here we go with the bindings stuff. Although C makes sense for a lot of low level stuff, if you are going to have an object-oriented structure for something of any kind, and it needs to be native and fast at a fundamental level, (like the basis of a desktop environment) for god's sake make the structure of it and choose tools that are logically object-oriented. That means C++, and it is arguably the only thing C++ is good at. Bindings are just stupid for this sort of thing as you are quickly adding totally unecessary overhead. As Linus Torvalds says, make the core of it 'sane'.
"Apparently, C does not impose an API on you like C++, so it makes C a good choice for a library like GStreamer which is abstracted anyway."
This is an argument that has gone on for too long. See above.
"GStreamer has C++ bindings in KDE CVS i am sure. Juk uses them. glib and gobject are not huge. It is not a big issue. Why reinvent the wheel?"
Yes this is a valid argument, but it I suppose it depends if it is outweighed by the issues above.
"Another good thing about GStreamer is that it is very small and can fit on a handheld. It has already done this. It is useful in embedded applications. It also helps to use the same framework on different devices."
It really needs to be network transparent for this to really happen, and since you need plugins for that there isn't really too much point, so no, the stuff above wasn't flamey. These are questions GStreamer is going to have to answer.
No, it is fundamentally designed as a multimedia framework with very few capabilities. Most of the other capabilities can be added on as plugins. If you want to make it network transparent, add a plguin to do that. GStreamer itself is designed to not add any latency overhead to anything, so you should be ok.
GStreamer is small and very fast. Low latency. I do not know what fast at a fundamental level is. Its either it is fast or not to me.
Programming is always with challenges. One reason Microsoft got to where it is is because they did stuff which was hard, because they had to. If you think you can avoid the hard stuff, like using GStreamer in KDE because you need to make bindings to do that, then you will be without an adequate multimedia framework for 3 years, or you will be using xine or mplayer, which are good players, but not such good frameworks.
besides, if KDE decides to use GStreamer, the interested parties could just become actively involved in GStreamer, i.e., keep the bindings current and so on. If the bindins are written well enough, no one unfamiliar with GObject and glib would even notice a difference. That is why it is called abstraction.
In the beginning, GStreamer was meant for GNOME, but they changed, which is why they steered clear of requiring GTK for example. So you would expect a few GNOMEisms there. Its a heritage of their past.
> If you want to make it network transparent, add a plguin to do that. GStreamer itself is designed to not add any latency overhead to anything, so you should be ok.
Erm, come on. gstreamer has been acknowledged by it's authors as *not* network transparent, and not easily done. That's fine though, we probably don't need that in a desktop environment considering that the network transparency of arts was always broken :)
> GStreamer in KDE because you need to make bindings to do that, then you will be without an adequate multimedia framework for 3 years, or you will be using xine or mplayer, which are good players, but not such good frameworks.
Or using NMM.. it still has to be determined if NMM can support everything gstreamer can, or if it can be implemented within a year. This is why support was added in amarok.
What we have said is that GStreamer 'itself' is not network transparent and that such should be handled through plugins. Exactly as the post you replied to pointed out. Our sound server plugins for Esound, Artsd and NAS is one example. Another cool project doing network transparent media handling is http://subsignal.org/pakt -> Warzav Pak.
As for NMM vs GStreamer, to me the issue isn't wether project a or project b can theoretically do what GStreamer does. The fact is that making these systems takes an enormous amount of resources to create and maintain and for the free software community to spread our resources out over multiple projects will only accomplish that result that we all reach parity with Mac and Windows later.
You are overly playing down one important issue which KDE currently has with aRTs, one which would not go away when KDE chose to go with GStreamer: interested parties on the KDE side could *not* just become actively involved in GStreamer, the difference between KDE's Qt QObject C++ and GLib GObject C is too big. If it weren't we might never have had that many people bitching about aRTs without fixing/improving the itching parts in all the last years. Referring to the bindings as the way to hide away any potentially confusing difference is a joke in this regard, this will just further endorse the active/passive split aRTs caused in KDE before, basically keeping discouraging many multimedia related efforts within KDE at the most fundamental level already.
Imo the best KDE can do for version 4 is creating a native basic multimedia API with a flexibel plugable backend, making use of whatever audio framework and backend exist already or is needed for a specific application, environment or use case (ALSA on Linux, QuickTime on MacOSX, DirectSound on Windows, JACK for low lacency, MAS/NMM for network transparency, GStreamer for interoperability with GNOME, or something along this line).
> environment or use case (ALSA on Linux, QuickTime on MacOSX, DirectSound on Windows, JACK for low lacency, MAS/NMM for network transparency, GStreamer for interoperability with GNOME, or something along this line
That seems to be duplicating what NMM and gstreamer are already *doing*. It does seem good to not lock into one multimedia server, but gstreamer has been active much longer than arts has, which was primarily a one man show even three years ago.
(Ignoring the fact that you want a KDE native framework-framework so you can abstract out framework compatibilitites, essentially doing what the above frameworks are supposed to do in the first place...)
So your argument is that its better to implement a totally new and incompatible framework (NMM) which isn't as mature as the existing framework, possibly taking years to reach the point we are currenly at, just to avoid the possibility that some KDE developers won't want to learn Glib? And *that* is a better way to allocate resources?
Please, the whole point of a mature library is that users never need to know how it works because it just does. Sure there will be hackers who won't hack GStreamer because its in Glib, but I think you grossly over estimate the problem that poses when we're talking about a mature library a year down the road.
Cheers,
Ryan
"So your argument is that its better to implement a totally new and incompatible framework (NMM)..."
Incompatible with what exactly? You make it sound as if GStreamer is some sort of standard already, which it isn't of course. You could easily argue at this point in time that GStreamer is incompatible with NMM or any other framework.
"which isn't as mature as the existing framework, possibly taking years to reach the point we are currenly at,"
Judging from their current progress and crucially, their pretty excellent documentation, I doubt it. I note the use of the word 'we'.
"just to avoid the possibility that some KDE developers won't want to learn Glib? And *that* is a better way to allocate resources?"
The point is considering the logical object-oriented structure of something like a multimedia framework (or desktop environment :)), given the progress of the NMM guys, neither Glib or C programming should be necessary at all. It is totally unnecessary to create bindings and all sorts of unecessary abstraction crap just because of some peoples' attachment to Glib and C. You get the object-oriented structure of the system right from day one, without any need for bindings and overhead, and these days that means C++. For the vast majority of systems like this these days C just isn't necessary, and considering the size of many systems produced today, less of a good idea. Ditch Glib and C unless they are absolutely necessary.
Note the current arguments about using Mono in Gnome, and C being dead, and note the fact that KDE has never had, doesn't have and probably will never have such issues.
"Please, the whole point of a mature library is that users never need to know how it works because it just does."
No they don't, but they unwittingly see the effects of a poorly designed one.
"besides, if KDE decides to use GStreamer, the interested parties could just become actively involved in GStreamer, i.e., keep the bindings current and so on. If the bindins are written well enough, no one unfamiliar with GObject and glib would even notice a difference. That is why it is called abstraction."
Abstraction in this case means adding totally unnecessary layers into a system. A layered system is good, but you should always learn to cut out the unnecessary stuff, and on the 'Gnome' oriented development side I have never understood why they have never understood this. A good rule in programming is to design your system in a logical (in this case object-oriented way) and use good tools available that allow you to totally reflect that organisation in code structure, as well as being fast and efficient. If you can do this, there is no need for layers and no need for any sort of abstraction. That means C++ these days, and amusingly, it is why there is such a hoo-ha about Mono and C. Note that KDE has none of these problems, and probably never will. However, since no one on the Gnome side of things has ever managed to wrap their head around this concept I suppose it is a bit pointless now.
"besides, if KDE decides to use GStreamer, the interested parties could just become actively involved in GStreamer, i.e., keep the bindings current and so on."
Extra needless work. See above.
"In the beginning, GStreamer was meant for GNOME, but they changed, which is why they steered clear of requiring GTK for example."
I should hope not. Why on Earth should a multimedia framework of any kind depend on a graphical toolkit?
> Some of the things you say are very, well, "flamey".
Well, uhm... I tried to do my best for an objective comparison of stuff that has already been brought up on kde-multimedia and acknowledged by both gstreamer and NMM developers. I for one do want to see gstreamer become the standard multimedia API of KDE. I won't say that there aren't issues involving either of the projects though.
> What is wrong with GObject and Glib?
Nothing political about it, it's just that there have been terribly experiences with software that uses it in the past (e.g, arts).
I for one don't care about this.. just pointing out that other people do. Not as many as used to though.. most people have softened up to the political side. The technical side still remains though.
"Another good thing about GStreamer is that it is very small and can fit on a handheld. It has already done this. It is useful in embedded applications. It also helps to use the same framework on different devices."
eat this:
http://www.networkmultimedia.org/News/Events/CeBIT2004/index.html
I ws just told by Spy Hunter that JACK is only an audio server part of the Agnula project, the same project ALSA comes from.
http://www.agnula.org/documentation/dp_tutorials/alsa_jack_ladspa/
Now I'm wondering, is Gstreamer also a sound server in addition to being a multimedia framework?
Can it be used together with JACK?
Yes. You just need a jacksink for output, and you let JACK do its stuff. jacksink already exists.