[vlc-devel] commit: libvlc: Export libvlc_media_player_get_input_thread(). (Pierre d' Herbemont )
remi at remlab.net
Fri Jan 29 14:50:18 CET 2010
On Fri, 29 Jan 2010 14:37:15 +0100, "Pierre d'Herbemont"
<pdherbemont at free.fr> wrote:
>>> jb specifically said that he was against having extension exported in
>> And I think he's right. It wouldn't make sense. Those are UI extensions.
>> They're tied with VLC. Do you get Firefox extension when using the Gecko
>> engine?! Do you get Konqueror plugins when using WebKit? Of course not.
> But you have to see that this is not the same thing in the internal.
> VLC extensions are not tied to a UI. FF are. Extensions here are much
> like NPAPI plugins. Loaded upon certain conditions and a limited
> interfaces. This may change in the future right, but for now they
> don't. Unless you uniformize interfaces.
Err, as far as I can tell, the bulk of the extension work that J-Peg pushed
was generic dialogs support. If that's not graphical user interface, then
I'm not the largest VLC commit author by commits count.
And then the pre-existing LUA code interacts with libvlccore. In
particular, it uses the playlist. That does not make sense outside of VLC
proper; it simply won't work. So trying to get extensions to work with
LibVLC is just a waste of time.
If you want to use them in a LibVLC app, rip out the LUA code, and tweak it
until you are compatible with the VLC LUA. Really. That's just like the so
many browsers compatible with Netscape extensions.
More information about the vlc-devel