<div class="gmail_quote">On Mon, Nov 9, 2009 at 4:27 AM, Jakob Leben <span dir="ltr"><<a href="mailto:jakob.leben@gmail.com">jakob.leben@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>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).</div>
</blockquote></div><br>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)<br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>Best regards<br>