[Discussion] Services discoveries UI/UX
Context
On VLC4 master, IMO browsing services discoveries in Qt has major problems (beyond the performance issues due to I/O on the UI thread on create and on destroy):
- all the detected "devices" are mixed up, to the point it looks meaningless;
- all the SD are started when opening the Browse view, causing unsolicited network requests (impacting performance, privacy, security…)
To illustrate the first point, here is a capture of the browse view on my machine:
Hard drives appear at the same level as pulse audio devices or v4l2 screen capture. There is an additional Applications
"directory", which is a actually a v4l2 virtual folder listing all the applications which can be captured… It is very confusing.
Current design
Each services discovery exposes a tree of media.
It is assumed, by convention, that they expose devices at the first tree level, and media at deeper levels. Typically, the tree exposed by a services discovery looks like this:
SD
+- device1
| +- media1
| | +- media1.1
| | +- media1.2
| | + …
| +- media2
| | +- media2.1
| | | + …
| | +- media2.2
+- device2
Because the user may not care whether a detected "device" comes from avahi, mdns or whatever (they want to see their device without even knowing about services discoveries), it has been decided to "hide" the service discovery source by merging the first levels of every SD tree into a single root:
as detected as displayed
----------- ------------
+- SD1 flatten +- ALL
| +- device1 =======> +- device1
| | +- media1.1 | +- media1.1
| | | +- … | | +- …
| | | +- … | | +- …
| | +- media1.2 | +- media1.2
| | | +- … | | +- …
| | | +- … | | +- …
| +- device4 +- device2
| +- … | +- media2
| +- … +- device3
+- SD2 | +- media3.1
| +- device3 | | +- …
| +- media3.1 | | +- …
| | +- … | +- media3.2
| | +- … | +- …
| +- media3.2 | +- …
| +- … +- device4
| +- … +- …
+- SD3 +- …
+- device2
+- media2
Confusion
But in practice, the devices detected by services discoveries are very heterogeneous. For example, a hard drive should not be at the same level as pulse audio devices. Moreover, some devices are meaningful only within the context of their SD: Desktop
and Applications
are meaningful only when you know that they are exposed by the v4l
module.
Also, as discussed with @chub, some network SD may expose devices that could not be opened. And since several SD may expose the same device, we randomly can or cannot open a network disk. So merging devices may cause confusion even for the case it was supposed to "simplify".
Since the purpose of this "tree merge" is to expose devices without even exposing services discoveries explicitly, then this implies that services discoveries (either all of them, or a subset configured in some settings) must be implicitly started automatically.
Suggestion
Therefore, I think that the "service discovery" level should be restored (i.e. we should not merge the devices from all services discoveries into a flat list of devices, but group them by SD).
This would also simplify solving point 2 (i.e. not opening all SD on start/browse): a SD could be opened when the user explicitly requests it.
I agree that ideally the user wants to see its devices with minimum knowledge about "services discoveries". I don't know if there is a way to keep this objective without showing confusing "merged" content and avoiding to start all SD automatically. But between grouping by SD (as VLC3) and merging all devices (VLC4), I prefer the former. Maybe there are other solutions…