make_it_cool: kdelibs/kdemm

[Ryan Gammon]

Michael Donaghy wrote:

>Sort of like how kaffeine allows xine or arts or mplayer backends to be 
>embedded into it, and can embed itself into other things?
>  
>

Yeah, that's the general idea. I make no claims of originality here :) 
Totem, Kaffeine, RealPlayer for Windows and Mac, and most other media 
players have some concept of alternative / multiple engines, though I 
haven't found anything that's desktop-agnostic yet.

>Sounds good, but makes me wonder, is XEmbed meant to replace KParts?
>  
>

I think XEmbed is a technology that underlies KParts, bonobo, etc (?) -- 
it's a fdo thing.

>Sounds good but I wonder about overhead. AIUI you want player clients and 
>engines to communicate via DBUS, but at the moment that means translating 
>from Gtk style in the helix client to DBUS and then translating that to Gtk 
>or Qt style at the engine, at least with the current engines. There'll 
>probably be a third layer of translation needed to use xine or mplayer as the 
>engine. If the engine is doing its own drawing we won't lose anything 
>performance-wise there, but what about latency on things like pausing the 
>player?
>  
>

DBus should be fairly responsive -- current implementations appear to 
communicate over unix domain sockets.

>Yeah, but there's already too many sound servers around and there seems to be 
>a movement against them. Does alsa dmixing support having a different volume 
>for different streams which are playing together? 
>

Not to my knowledge...

>If not, could it? 
>

Yeah, I don't see why not.

>Because I 
>think that's the only way you'll get it in all distros.
>  
>

:)

>Provided it doesn't induce too much latency, sounds very good. No more messing 
>around o get arts to play my mp3s and xmms my streamed ones and xine my wmas 
>and realplay my real streams, just set it up once and then I can use my 
>choice of frontend to do all of those, that's the idea right? 
>

Yup, that's the idea.

>Players like 
>amarok which at the moment has to code separately for arts and gstreamer 
>backends could just write one set of code and it would work with all 
>backends, even some which haven't been written yet. If it gets popular this 
>will be a big step forwards.
>  
>

Yup. Makes it a little easier for kde apps to try out Helix too, 
particularly for apps that just need the basic playback functionality 
that would be exposed by a simple dbus api.

>Sorry if you've said before, but how do you decide which backend to use for 
>which file? Do engines "advertise" what types they can play somehow? Does the 
>user have to choose?
>  
>

Well, with helix player, the plan is to try helix first, and then fall 
back to whatever else is on the system.

The easiest thing for other apps to do would be to give the user a list 
of media engines, and let he/she put them in some sort of order.

One could get more complicated by allowing per mime-type configuration 
-- not sure how compelling this is though :) It would mean that each 
engine would have to be queryable for its supported mime types.

-- 
Ryan Gammon
rgammon at real.com
Developer for Helix Player
https://player.helixcommunity.org