apachelogger wrote:Hey everyone. Having used the nested structure with devices on the first level and apps on the second level for the better part of this week, I think it feels really good. In fact, it appears that everything is coming together so nicely that the applet is almost release quality already \o/.

Sounds awesome!

There are still a couple of semi-relevant features missing though as they mostly have not been considered in the design so far. So I went ahead and made a list off the top of my head.

Whoa, I never imagined there was that much to consider!
Okay, I see now that it doesn't make sense to make these decisions independently for each feature, since we'd end up with endless detail discussions and lose the overview at some point.
Also since every individual usecase for a volume Plasmoid is different, we have to abstract from our personal needs and decide whom at what to focus on.
Therefore I'd suggest the proper™ approach to this (something we should have done right from the start actually, but better late than never):

1. Define a project vision
2. Define one or more target persona(s) (if we have more than one, we also have to define the primary one)
3. Define user scenarios we want to support
4. Define for each scenario whether it's a common or uncommon scenario for the target persona(s)

Once we have that, we can try to e.g. put all the common scenarios in the Plasmoid and the uncommon ones in the KCM.

PS: I am also trying to get you a way to easily test what I have, more on this next week I guess.

Sounds good!

apachelogger wrote:Features possibly not suitable for applet (KCM?):

...

• Display of virtual devices (e.g. monitors allowing the use an output device's output as input) and virtual streams (I don't think there is anything implementing a virtual stream at this point).
  ...

Thanks for your work! Really nice! Kudos!
Redirection out of an applet would be really handy, e.g. you listen to something you want to share with others in the moment you speak to them (e.g. over a voip application), or you are having two conversations using different programs and want that participants of both conversation can as well hear each other.
The reason I would really like to see this in an applet is the same reason that speaks for an applet itself: Easy accessibility without having to do window management. I think the KCMs should more serve a purpose for configurations and stuff, but I consider this a basic, though advanced feature.

Clicking on a stream could expand and allow assigning the stream to an input device. Is this no option for you Harald?

What is currently missing is an indicator to tell which device / application is producing sound. Like a flashing "Now playing" label and the sound icon, the same way a charging battery is displayed in "Battery and Brightness".

Is there any further progress on this? I'd love to see a kmix replacement before the next version releases.

enoop wrote:Is there any further progress on this? I'd love to see a kmix replacement before the next version releases.

Got sidetracked by other work.

Do you have any plans on finishing this before the next plasma release?

I am not sure that would work out considering the holidays are coming up and release is at the end of January. That being said, I do not think a first release needs to be as part of Plasma anyway.

Any chance there repo up somewhere with this code or is this only mockup stage? This is the last piece i need to make my plasma desktop complete since 5.2 rolled out. veromix was good in SC4 but the creator does not plan on porting to 5 since they would have change langauges to do it. Kmix simply does not cut it if you have multiple device you want to output to at different times.

One thing I would consider is inverting stream and device.

I visualise it something like this.

Master Volume 45%
{------o------------}

Tomahawk 45%
x Analog Speakers
{------o------------}
- TV HDMI

Kodi 45%
- Analog Speakers
x TV HDMI
{------o------------}

I think this arrangement would solve a few issues.
- Won't have to hunt down the app on every device.
- It is app focused approach.
- Allows the user to easy pick where to direct the apps output.

The app focused view is how i would argue how most users think about their sound. Is my music player loud enough, oh my master volume is low. Let me turn that up. Wow that notification just interrupted my jamming to my music let me turn those down. I don't know of anyone who thinks, "the sound device that goes to my tv i need to turn up my video stream audio output on that."

Current concept:
https://community.kde.org/Plasma/Volume#Concept

Sebastian Kuegler rightly suggested on IRC that Susan wouldn't use the mouse wheel to change the volume, so I am reasonable certain we'll want a more advanced persona in the mix as wheeling seems like a very expected feature. Suggested was going for Carla and Raj from https://community.kde.org/Plasma/Worksp ... t/Personas

Anyone got any thoughts on this?

Carla is quite similar to Susan best I can tell. Maybe just adding Raj to Susan would cover your bases well. Cool to see the underlying concept captured so well!

I agree with Andrew: Nice write-up!

The only thing I'd change is the User Stories. They are currently a mix of user stories and scenarios, and I'd strongly recommend to split them up. All the general context description should go in scenarios, whereas the detailed action descriptions should go into users stories. Those should then also be expanded with how the system reacts.

The advantage of that is that the scenarios can then also be used to derive further user stories from them if needed, and that context is clearly separated from interaction design (there might be other solutions that apply in the same scenario, for example wheeling over the icon should certainly not be the only way to change the volume).

Oh and just to make clear what a vision is good for: With that vision, the applet will be clearly restricted to everyday-use volume setting. No fancy moving streams between devices or stuff like that. If we stick with that vision, all of that would have to be done using other means.

I'm interested in getting the volume applet also in the lock screen. This might require a different user interaction depending on what we want to expose there.

apachelogger wrote:...
Features possibly not suitable for applet (KCM?):
...

• Display of virtual devices (e.g. monitors allowing the use an output device's output as input) and virtual streams (I don't think there is anything implementing a virtual stream at this point).

...

I'm not sure if I'm getting this right, but consider the following scenario: I have two sound cards, one being an internal 7.1ch chip and one 2.0 BT headset. I split my internal card into a 5.1 and a 2.0 device using pulseaudio's sink remapping. These appear as virtual devices in pavucontrol. The virtual 5.1 device is connected to my 5.1 headset, the virtual 2.0 device is connected to my stereo speakers.

When I listen to music, I usually listen to it on speakers, but if everyone's sleeping (like now) I usually switch to my 5.1 headset or my BT 2.0 headset (if I want to be able to move around the room).
So I'd very much like to be able to do that from the applet, so I guess I want to have virtual devices shown on the applet as well.

It does not really make sense to show the internal card in my case though, so maybe you could allow the user to select which devices should show up in the applet.

So it seems the first version of the applet was shipped with 5.4. I have noticed some problems with it and posted about it here. Since they're mostly design issues in nature, I'm not sure it makes sense to report them as bugs. I will do so anyway if I don't get any feedback in that thread or here, though.