Hi Lars, On 13/12/21 11:14, Lars Knoll wrote: >> When the new QtMultimedia was announced [1], there was a mention that >> the Radio API was being removed (by the way, there is no mention of this >> removal in the migration document [2]). Did it happen because of a lack >> of time, or were there other reasons? Is it going to come back? > > It wasn’t mentioned because the API was not implemented in any of the > backends we provided, ie. it was non-functional for regular Qt packages.
Ah, indeed I was a bit surprised looking at the v4l radio plugin code, because it looks like it does not implement all of the the pure virtual functions declared in the QRadioTunerControl interface, so I was wondering how it could possibly work. :-) > We could consider having one plugin for all of Qt MM. But I certainly do not > want to go back to what we had in Qt 5, namely one plugin per functionality > group, as that makes things extremely messy to implement. I see, and that would also fit our use case. > I would be fine with an additional backend maintained inside Qt MM, but it > also depends a bit on what you prefer. Btw, how is your backend different > from what we have in Qt 5.15? We delegate audio/video playback to a separate D-Bus service. In this way the playback can continue even when the application is moved to the background (background applications get stopped in Ubuntu Touch after a couple of seconds). There are also a few other benefits to this approach (resource management, delivering the playback state via a global MPRIS interface, etc.), but this is by far the most pressing reason. > One thing I can say already now is that I do not want to go back to Qt 5 > times and make the backend API public. We will need the freedom to change the > API between versions where required. That's also fine. > It is already available as private API, and there’s a hook to load a > different backend in 6.2. Have a look at > QPlatformMediaIntegration::setIntegration(). We’re using it to test the > frontend API with a dummy backend. > > So you should be able to do most things today, but you’d need a global > constructor functions that sets up the integration somewhere. Right. So if we don't want to patch Qt, we should either get our platform integration upstreamed, or introduce a plugin loading mechanism that instantiates a QPlatformMediaIntegration subclass, possibly using an environment variable for the selection. Anyway, the situation doesn't look as gloomy as I initially thought. And we are not talking about the immediate future, so it may be that by the time we move to Qt6 things will have already changed. :-) Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
