<div>On 1/11/07, Mikael Hallendal <<a href="mailto:micke@imendio.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">micke@imendio.com </a>> wrote: On 1/11/07, Mikael Hallendal <<a href="mailto:micke@imendio.com">micke@imendio.com</a>> wrote:     I think it would make sense to have a call to play up a sound file,     for example for when a new message arrives in your inbox. I think     however that anything more advanced than a simple "PlaySoundFile"     doesn't fit in the current design of DAPI. Under the dapi.sound interface, there is a simple Play method. Such methd, I would say, should not be limited to take only a filename. A URI at least  would be much nicer. Another thing that comes to my mind, is that PlaySoundFile under dapi has only a limited chance to succeed on a cross-desktop project: if you need such function, then you probably need to do more advanced things, like getting metadata (even if there is other way for files, but lets talk about URI instead). Why? Because, if you refer to a soundfile, that means you are probably not willing to play a sound event. Right now, I only see a file manager for this "file" need (see Nautilus sound, for example). But a file manager need more things, like changing the playing state, seeking (and it would be nice, of course to set fadein/out!). Basically, you need some control. So you need to define an object that implement a sound.playback interface. Let's talk rather about events (I see much more use in this case for cross-desktop applications - even if such call should come from a notification daemon/api), then you will have to give an id. Hopefully, all this can be handled easily with the same method, or at least, I guess it would be nice). And I agree, then, you probably don't want to see further object/handler/control. But if you start thinking about theming, then you will need some other object/interface like dapi.sound.theme. Still, lets stick to something simple: Name, and PathList would be enough for sound.theme (that should implement the waited fd.o spec). What if you have to implement a classic game? background music would need some control, volume level, and you might appreciate looping (see the very simple QSound API that has been strimmed down over the year. They still provide Loop property). Hmm. No, let's talk about the cool things. Space positionning (an event come from the position of your window, interesting, would it be ?). Priority! Of course, I want to hear my phone ringing even if my resource is busy playing something else - and that would be nice if the other apps lower.I'll call that playback.advanced interface. So we end up with a kind of list of requirement that would be nice to provide. If you look at the use case for the desktop (I have done that, even if I think that developpers are deaf because they don't use sound or because it's not big priority, or because we don't have a clear way to do it, or because it's boring to end up writing the samething all the time for dealing with PCM streaming, negotiation...) I try to unify desktop applications needs with a quite simple interface for people, like me sometime, who don't really care about the default API/backend, but would like to have a simple API that make a best effort for any desktop. Now, I can understand that maybe, DAPI is not the right place: I can imagine reading the specs, that you can be expecting another completely different behavior, like "opening the default media player for this particular desktop with this sound (a la xdg script)". But I would suggest another api for that: OpenSoundFile or even OpenFile (ala xdg-open). The discussions take place to see where it could fit (we even thought about PortMusic or PortAudio, it might finally be PortDesktop, but I would find that a bit funny)     More advanced functions such as setting volume, fade, loop, set     position etc would probably fit better in it's own component for such     applications (music players comes to mind) that need that. And everyone write the same thing (in different ways, yes) to handle the very same control over audio playback. But I don't really target music players (I target my_first_music player, yep). Believe me, I know that music players need more advanced things :) Even a common desktop sound API will need other properties if they don't come from other common API (like program name, application name, pid, user,...). one more thing I am considering is to add a window id to the sound object. But there might be other way. There is tons of things that we can define under DAPI. I just don't know what is the border line for you guys :)     > Regarding DAPI "core", what about a common vtable for main loops/     > events, similar to the one of D-Bus (instead of just leaving fd to     > watch for)? It is interesting for different services implementation     > without big limitations, I guess.     I take it this refers to the IPC layer that is not being used in the     GNOME Dapi Daemon (where we use D-BUS). The idea is that all     implementations will use the same IPC layer and as far as I know the     current idea is to use D-BUS for this. The idea is that I don't want to care if it's an underlying IPC. Sometime it does not make sense to use IPC (for example with play sound or open!). Still the DBus interface should be provided also, I can (to some extent) agree and vote for it. But async calls are important. And implementation of different static lib version of the abstract api would need an event loop. And we face the very difficult and embarrassing problem to define a common main loop for various things (and other related needs).     I can only talk about the GNOME part of DAPI but we are currently     waiting a bit to see where the D-BUS GLib bindings will go with     regards to generating the client side library from the D-BUS     specification XML. Ok, one flavour with Glib (I suppose you are talking about GObject instead). And what about a plain C implementation that I suggest? That's the reason why we can say that any flavour of an interface lib should share the description of the main loop dbus currently use. That would be great. Think about it, we could have: - a sound lib that implement the C interface and use pulse or alsa directly    - a plain C dapi library using the sound lib (and hence no DBus) OR/AND DBus for other things (that is none of my business if I write C app)    - a dbus daemon using the same sound lib for implementing DBus calls. You end up with a nice integration, and still cross-desktop with different flavors choices (choosen by ISV or power user). I won't develop other ideas I have, I would probably regret it later :) Regards, </div>-- Marc-André Lureau, GSmartMix