On Tue, Sep 27, 2011 at 5:08 PM, Mike Blumenkrantz <m...@zentific.com> wrote: > On Tue, 27 Sep 2011 12:12:22 -0300 > Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > >> On Sun, Sep 25, 2011 at 5:00 AM, Carsten Haitzler <ras...@rasterman.com> >> wrote: >> > >> > On Sun, 25 Sep 2011 04:14:55 -0300 Gustavo Sverzut Barbieri >> > <barbi...@profusion.mobi> said: >> > >> > going to have to kill off your dbus idea. reality is the pa dbus api is >> > experimental (testing branch). i'm staring here at ubuntu 11.04 - no >> > pulseaudio dbus service. as jeff said: >> > >> > <jeffdameth1> k-s: i heard the dbus interface is in a testing branch that >> > will be merged with pulseadio 1.0. so this will take some time until >> > adopted >> > >> > so... the only way to make it work is via the internal protocol - bare >> > metal. unless you want to wait 2 years for it to stabilize, be adopted, >> > released and actually on most peoples distributions. :) hands up those >> > people who really desire to delay e17 release until then? :) >> > >> > yes the mapping of pa channels to the mixxer channels was cumbersome. i >> > fixed it up to "work" and thus the id + 1 thnig so null (id 0) channels >> > dont break stuff. as such the mixer infra doesn't quite cover everything >> > pulse does, so really u'd need an alternate ui and infra setup. you can >> > share the same gagdte and popup slider, but the rest would need to be >> > different. >> >> PA 1.0 was released today... and what a shame WE avoiding projects >> just because they were not released, in that sense people should still >> avoid Elm and E17? :-) > > We aim to support the current version of pulse at the time of E17's release. > Unless we delay the release of E17 another few years, the current version of > pulse will NOT be 1.0. It will be some 0.9.X version with no dbus api and an > irregular (at best) library api which creates a large number of unwanted hard > dependencies. > > Going with the native protocol allows compatibility with pulseaudio versions > down to 0.9.16, and GUARANTEES future compatibility with versions > 1.0. > > There's no real downside to using native protocol for quick mixer > module additions aside from the amount of work that I personally have to do in > order to reimplement the protocol in a usable form. > > Knowing all this, if you really want to rewrite the mixer module to have full > 1.0 dbus pulseaudio integration then by all means do so. But let me know > beforehand so I don't waste any more time looking at the awful codebase which > is pulse internals.
As I said I have no problems with not using DBus, given that I'm not the one that would care about doing it. I'll need to figure out when I'll have time to do this, but likely what I will do is: - create another mixer with a copy of original code, pre-pulse - make that code take runtime plugins, as opposed to compile time - extend the API to consider N volumes, instead of left/right - add callbacks to notify of changes, like removal of cards, sinks or sources - change the main list to query sinks, sources and applications. Instead of checking for capture or not. - send the code to you - wait you to test - commit to svn Does it sound like a good plan? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
