[vlc-devel] commit: libvlc: Export libvlc_media_player_get_input_thread(). (Pierre d' Herbemont )

[Rémi Denis-Courmont]

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
>>> libvlc.
>>
>> 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.
> 
> Sure.
> 
> 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.

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis