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

Jakob Leben jakob.leben at gmail.com
Mon Nov 9 05:52:09 CET 2009


On Mon, Nov 9, 2009 at 4:27 AM, Jakob Leben <jakob.leben at gmail.com> wrote:

> I did mean to have them always active. That is, to activate already at
> startup all those enabled in preferences (while on the other hand changing
> preferences should have immediate effect, for the sake of practicality and
> being user-friendly - which I would say is just as well a reason for
> activating the preferred ones already at startup).
>

I have to explain further: I'm talking about the GUI (or generically: the
top-most client) that shall activate all preferences-enabled SD modules when
it's started (coding this into the core SD system would obviously be a
waste)

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.

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).
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? 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? 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.

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? We could save memory by having
separate classes for nodes / plain items - the largest amount of items will
usually be plain items.

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20091109/325ab337/attachment.html>


More information about the vlc-devel mailing list