As the title suggests. Really cool feature to only be available on X.
This features only needs pulseaudio and get the netwm.pid field from e_client struct filled accordingly.
I tested it and it works as the e wl compositor set this field.
So, already done ?
Ok, I've tested rage on wayland. And I confirm it works but not at 100%.
The volume control isn't displayed into the window decoration but could be accessed by the volume control menu from the window. So the mixer module have associated the window with the pulseaudio sink.
I think the problem come from how window decoration is catched on enlightenment and the code path used by rage application. This path don't include volume control on the decoration (no frame_object into compositor). Need to investigate how and if we could resolve it.
Into the window menu. Click on the upper left window icon. It display a menu where you can find a volume control "volume".
After some tests, it seems it only work the first time you launch rage into e (maybe a e bug, not sure yet).
About the volume slider in the window decoration on wayland is a bigger issue than I expected.
Elementary is providing the window decoration on wayland(csd). So, if we want to allow a volume control on the window decoration. We need to make this into elementary not e.
We could make an API in a generic way(Not only pulseaudo), so all of the apps who use sounds could use it.
I think about mpd clients, mpris clients and others ... and let the app choose how to do it.
The drawback of this, is the app must provide it. It isn't a gift anymore.
This has to be done by the app PROCESS on wayland, but it doesn't need to be done by the APP. This could be done in EFL.
Emotion and Elementary could "work together". Frankly Emotion directly could expose every video object that has audio at all as a control volume gadget to the window as some gadget to swallow into a box of multiple control gadgets (if the window supports that kind of swallow in the theme).
Another option is elm win/elf ui win to listen to pulseaudio info like e does and filter for "itself" and then provide those controls. I'd rather go the above explicit one in elm because it can then possibly allow us to add APIs to emotion like emotion_object_auto_volume_control_ignore_set(obj, EINA_TRUE); disabling this automatic volume controls in the titlebar for that object if the app explicitly wants to hide it from this.