[vlc-devel] Qt media browser (playlist selector) reorganisation

[Rémi Denis-Courmont]

On Mon, 9 Nov 2009 05:52:09 +0100, Jakob Leben <jakob.leben at gmail.com>
wrote:
> But on side of the core, this would be much more effective if we had
> per-node fetching of children in the SD interface, instead of modules
> fetching all their hierarchy when activated. I think this is a great
> future that should be implemented and I would like to implement.

Yes, that would be useful. But it's quite tricky. SD plugins need to be
able to update items and sub-items. Currently, they can only add and remove
them. Also currently, there is only one level of nesting. And then, if an
SD plugin updates one of its items... how do you propagate the change to
the playlist, in case the items has been added to the playlist?

So, there is quite much work...

> I have a problem thinking about it though: how does the per-node fetching
> combine with a module's continuous notification of items added / removed?
> For example udev module monitors cd tray continuously and sends
> spontaneous notifications to clients (not in direct response to any
> request of theirs).

Hmm... that's not an exception. Pretty much all SD plugins work that way.
Shoutcast is a (degenerate) exception among SD plugins.

> So then, if we have a module that has this kind of monitoring at
> some lower level of hierarchy, does it notify clients only about
> children of nodes that have already been fetched?

There has to be a way to do that. Otherwise, the plugin will be effectively
non-functional from the user perspective.

> Then if there is many clients and one has issued the fetch request
> for children of a node, but the other hasn't yet, do both get notified?

Do we really want centralized SD instances when there are more than one
interface? If it simplifies things, we could make SD plugins children of
the interfaces. This will add some memory and processing overhead in the
_unlikely_ case that there are more than one SD-capable interface, but who
cares?

> However, it's not the easiest issue to implement per-client
> notification policy, we would need an event system that to my knowldege
is
> not yet implemented in vlc.

You can just add event callbacks set by the owner of the instance, rather
than the plugin. We already have something similar for video output mouse
events.

> One simpler option would be to have per-node event manager so clients can
> individually register for specific node's child added / removed
callbacks.
> Would this be too much of a memory overhead?

That does not work. When a SD plugin adds a new item, it wouldn't know what
callbacks to invoke, since the SD owner would not have had the opportunity
to set them.

-- 
Rémi Denis-Courmont