[vlc-devel] [PATCH 00/10] Item browsing system
remi at remlab.net
Tue May 27 14:18:40 CEST 2014
Le 2014-05-27 17:30, Julien 'Lta' BALLET a écrit :
> On the other hand, having the state somewhere inside of input_item_t
> doesnt mean it has the share the same lifetime.
I think that's impossible. As long as the input item exists, it might
potentially be expanded ("browsed into"). So as long as the input item
exists, the state will need to be retained.
> Lets face it, at
> some point, any solution not including rewriting the playlist will
> have to work at least a little bit with the input_item. I wont say
> it makes me happy, but doin
> ight be out of a realistic time frame for me alone :) (Any help on
> that topic is welcomed, please drop in the thread if you feel like a
So far, it seems you only want to clean up the directory expansion
within the playlist, but not add dynamic updates. For that modest
purpose adding a third read callback to access_t (pf_read_item or
pf_readdir or something) should be sufficient. This allows replacing the
XSPF generator from the directory plugin in a cleaner and more generic
fashion. Then there is no problems with storing state (it can stay in
the access_t plugin as before). The changes to the core would be much
more contained, and I see absolutely no needs to reinvent the input
Your browsable flags would probably still be useful for fine tuning the
playlist GUI, but not for the core.
Either way, that won't solve dynamic node updates, so I doubt it will
be good enough for UPnP.
> As a sidenode about inotify, theres another issue related to the
> "outstanding file handles/ what-nots issue": by default, the number
> watches allowed per-user by the kernel is pretty low, that mean we
> might have to choose which file we want to watch.
Oh sure. That's why I said you need more state than a single pair of
flags to support dynamic node updates. I would guess you need to know if
a least one UI is (still) showing that node expanded.
More information about the vlc-devel