The 2800k overhead are lots of configure and makefile magic implemented in a generic way to cover most, if not all and then some ways to get the build to work on different systems. You could write the configure and makefiles from scratch and the resulting overhead would become negligible, but the time you end up using maintaining and debugging the buildsystem for different targets are time you could spend writing code for the application. Or you could remove unneeded parts from the generic configure/makefile's, but the cost are again time. You trade size of the source tree against development time, since this has no effect on the compiled app it's a good solution.

But if PyQt binding uses autoconf/automake (I don't remember, I'm not a Python fan) then it have that large overhead itself, so indirectly you still have it.
Not to mention the overhead in the build system of KDEBase/Libs/...

Probably the only solution could be a "runtime" for configure, so most of its stuff is on its own package and not in the source tarballs. But there are a lot of people (not me) claiming HD/RAM/BW are cheap and wanting for self-contained packages, so I'm not sure how such idea could be taken.

You are going too far, the point was about applications not the whole framework. Folowing your reasoning you forgot to mention the buildsystem for X, the compilers and the kernel, and that's ridiculous. The requirements for installing an application either binary or from source, are that the needed infrastructure are in place, library's etc. Anything concerning install of those have no bearing on this case, as they are already installed.

Based on the quality they now have I consider the Python, Ruby and Javascript packages from kdebindings as an integral part of KDE, and I rate it as a bug if they are not included in the distribution.

That's because PyQt needs python to be installed already. Automake/Autoconf relies on only a few tools which are preinstalled on almost every Unix system (like HP/UX, Solaris, AIX). However these tools are implemented differently on each Unix, so Automake/Autoconf has to bend over backwards to be compatible with everybody. Plus it has the capability to check several hundred compatibility issues that are different between Unixes (plus your own checks that you define) so that your source code can be compatible. Python is the same everywhere so PyQt does none of that. It would be nice if C was the same everywhere too, but for historical reasons every Unix is different. Luckily Automake/Autoconf are here and do the compatibility work for you, at the price of a couple of MB of automatically-generated files. It is a good trade-off.

The auto* files are hardly autogenerated. Every line of your configure file was written by someone as a macro. Also, pretty much noone understands the things, so if you need to test for, say, libmikmod, you just don't, and it seems to be portable, but isn't.

As for auto* requiring only a few tools... well, that's their problem. The way they are written sucks.

Mind you, I have nothing better to offer, except maybe publishing programs in ways that force platform vendors to wake up and offer a decent platform to work on, but that's just wishful thinking.

Python being the same everywhere is a python *plus* as a platform. C and C++, as a platform, don't have it. There comes my point about C and C++ being lame in that area.

Of course "The auto* files are hardly autogenerated", is python autogenerated? The executables of your c(++) code. They ARE autogenrated, after you manually give some command. So first define autogerated, but then still this is a silly discussion, because you are making a comparrsion between two different things that are made for different goals. When c++ was invented phyton was just a snake I guess. So many people know c++, so its a waste of time, for a lot of them (they can make good money with this knowledge) to learn python. So python is newer, so it SHOULD be better. Else it was a lame job too invent it at the first place. Too give all those good c++ programmers a more easy job by publishing and share there great ideas and work with everybody on a lot of different systems, designed for a lot of different tasks, auto* was made. Very handy, with unfortanatly a lot of overhead. Owh my .... Lets start a disgussion about it. because. WE python guys don't have this overhead. Whoopsy we are much better. Well in that area. okay you made your useless point. A ferrary IS faster but cannot transport the milk from hunderd cows. Whow the milk tank is slow, but hey it CAN transport a lot of milk. Thats why they are both there. So if you compare those two completlye different things, compare them fully, test them, write a report and publish it :) Or just code good programs :).

Will anyone be creating C++/Qt bindings to GStreamer for KDE 4, similar to what's happened with D-BUS? Judging by Gnome its a powerful backend, but it doesn't seem to mesh perfectly with KDE style code.

Also, does anyone know why is the author using greater than and less than instead of plain old equals when querying the GStreamer state? I'm not saying this is wrong, I've just never used GStreamer before and I'm curious to know what's going on there.

The greater thans are there for no real reason. You could replace them with equals and it'd work just as well (state changes are guaranteed to be one-level at a time). I guess I use greater thans to make the purpose of the code (as in: checking a state shift) somewhat more clear.

Wow, could be a nice starting point for kmplayer having a gstreamer backend too ... only get seg faults in KissWindow::open... ah I should use the File dialog (silly me, the mac menubar).. hmm no video only sound (mplayer says
[mpeg4 @ 0x84857a8]looks like this file was encoded with (divx4/(old)xvid/opendivx) -> forcing low_delay flag).

Hi Koos, you want to use at least gst-plugins 0.8.6 (as the website also mentions). 0.8.5 will work for audio, and with a small hack it'll work for video too, but I don't want those hacks in example code. ;-). The hack is that you need a different property for getting the video size in 0.8.5 than in 0.8.6. With current code and 0.8.5, Kiss will always claim that the video is 0x0 pixels, and thus not show the video window (user experience: no video). For playback of divx, you will additionally want gst-ffmpeg. This package is not yet available in Debian's main archives, but it's available in several unofficial repositories. Ask the debian people for details. RPMs for both gst-plugins-0.8.6 and gst-ffmpeg are available all over the internet.

If you want to add a backend to kmplayer, please do. I'll try to help if I can.

Got it working now for a MPEG-PS stream w/ 0.8.6 debian/unstable. Does crash on exit but that's for kmplayer no problem :-) FFMpeg can wait .. Did need to resize the window a bit for the video actually stayed, but I had that with Xine too.
Give me a few days and I'll have something to start with.

More and more applications arise that use a the backend (GStreamer, NMM, ...) directly and in its own way.
It think its time for a KDE standard way, a abstraction layer, so that there are not too many KDE application which are fixed on one backend. Me, for example would prefer using NMM.
The abstraction layer should be agnostic of the multimedia backend used.

But not for complicated audio funcionality. The layer that will exist will be suitable for things like the track playing preview thingy in K3b, and possibly also in juk. It won't be suitable for a dedicated media player. For that gstreamer looks (to me) to be the best option, but what would be nice is an option "approved" by kde. (of course gstreamer has the approval of the, ah, "other people")

True, but the time needed to add network transparency to GStreamer would be smaller (15 days of work to design and implement NMM style or better network transparency was our estimate when we discussed it last) than the time needed to create all the GStreamer plugins etc. for NMM.

KDE is often deployed on thin-clients. The applications run on the server and display on the thin-client. It wouldn't do to play Kiss on the server and have the sound play *on the server*. The sound has to play on the client.

Correct, it sets CPPFLAGS instead. Requires automake >= 1.7, though, won't work with 1.6 (which you appear to be using). I've disted using 1.7, so you shouldn't see that unless you re-ran make -f Makefile.cvs.

Now if only GStreamer wouldn't crash and burn on startup, I could try some of these new KDE applications. But since the aRTs based apps work just fine, I don't feel any pressing need to debug GStreamer...