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

[Pierre d'Herbemont]

2010/1/29 Rémi Denis-Courmont <remi at remlab.net>:
>
> On Fri, 29 Jan 2010 14:18:31 +0100, "Pierre d'Herbemont"
> <pdherbemont at free.fr> wrote:
>>>>> I hope this isn't Lunettes/Glasses
>>>>
>>>> Why would you not hope so?
>>>
>>> Because it's rather scary if one of the main author of LibVLC and a
>>> committer to the VLC repository won't fix the LibVLC API instead of
>>> adding those hacks.
>>>
>>> get_instance() was meant for external people who can't or at least won't
>>> afford to improve *our* API.
>>
>> 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.

>> I am work-arounding.
>
> And I am against exposing input_thread_t out of LibVLC.
>
> So do you work-around that too?

Yes, I will. Do I have any choice? Do you offer me any constructive solution?

>> I am all the for exporting a sound API for extension. I have a very
>> light one in VLCKit, I could reproduce it in libvlc.
>
> If extensions don't belong in LibVLC (and I do think they don't), they
> don't belong in VLCKit either.

This is your definition, they could belong in VLCKit, given how they
works now. When they will hack the UI for real this would be
impossible.

Pierre.