goal of kde-multimedia ?
neundorf at kde.org
Mon Feb 23 17:26:46 GMT 2004
On Sunday 22 February 2004 22:11, you wrote:
> On Sonntag Februar 22 2004 21:34, Alexander Neundorf wrote:
> > Section 4: codec libs:
> > mpg123/
> there's no mpg123 dir in cvs.
> > mpeglib/
> that one's patched.
Why do we need to maintain a patched version ? It's free software...
> > Section 1 basically does nothing else than implement an audio player
> > (with highly advanced capabilities) and a multimedia API.
> "Nothing else"? Isn't that enough?
Well, xmms did this for ages...
> > Section 3, these are applications which add real value.
> Value for whom? I don't use krec nor do I use juk. Your definition is
At least they are a bit more non-standard than a simple player.
> > Section 4, maintaining an own copy of codec libs isn't a good idea IMO.
> So write an artplugin for something that is installed on every system and
> plays mpeg files. I'm sure you won't find any lib (btw, xine and mplayer
> both have many of the used libs in their sourcetree as well).
We use free software, why not working with the original project and get our
required patches in ?
It needs some work but that's what I did for samba, mplayer, ieee1394 drivers
> > For sound people use xmms, for video mplayer (or xine). There are several
> > kde frontends for mplayer.
> Embedding the mplayer xwin is no frontend, it's a hack.
Hmmm. Isn't there also the UNIX tradition to use existing cli tools to build
bigger apps ? Having the video codec running in another process also adds the
feature that a crashing codec doesn't crash the application. And the
embedding works. Of course using a lib is cleaner.
> > IMO what we need is the ability for any app to say "play this sound
> > file", usually notifications.
> We already have.
Only with arts running...
> > So, what is the actual goal ode kde-multimedia ? Do we want to implement
> > our own versions of mplayer, xine, xmms, videolan with our own
> > super-integrated system or do we simply want to get some nice
> > kde-integrated multimedia apps out to the people ?
> I fail to see what "integration" has to do with xmms, it's a player with a
> gui on its own and has no backend to base any kde-frontend on. Almost the
> same applies to mplayer because it's no shared lib and all frontends I've
> seen so far do nothing but try to embed the mplayer xwin into theirs. This
> breaks way too often and is a crude hack.
For me it works 100% without breaking and if you consider the special
technique of embedding another X window a hack, ok, but I don't really see
> > PS.: Discussions about the bad code of mplayer are pointless, it works
> Yeah, a fact is a fact.
So what ? The code has some kind of structure and it works so damn well. It
isn't as beautiful as the Qt api, but it works and it is possible to
understand it. I don't think we need any "we won't use any crappy C api"
> > PPS: /me ducks.. even good old xmms can be used as a backend via libxmms,
> > works perfectly, plays all files, offers all functions, is rock-stable,
> > and with some patches the xmms-window can be hidden so you never see
> > it...
> You must be joking.
To be honest, yes :-P
But still, many of your arguments are: it's an app, no lib, it has a non-KDE
default frontend, we need patches for it, etc.
All this software is *free*. You can just send your patches there to add the
functionality which is missing. They won't be accepted after your first
attempt but if you stay pushing enough they will be accepted when they are
considered good enough. This also means that the patches will have to comply
to the coding standards of that project, and not our nice KDE style.
A last note: I did it for one project: using libxmms you have total control
over the sound files played by xmms, disabling the gui is no big deal. Feals
like a real library.
Work: alexander.neundorf at jenoptik.com - http://www.jenoptik-los.de
Home: neundorf at kde.org - http://www.kde.org
alex at neundorf.net - http://www.neundorf.net
More information about the kde-multimedia