[vlc-devel] commit: Added vlc_get_libvlc_object to libvlccore (Basos G )

[Pierre d'Herbemont]

On 16 déc. 08, at 09:26, "basos g" <noxelia at gmail.com> wrote:

> 2008/12/15 git version control <git at videolan.org>:
>> vlc | branch: master | Basos G <noxelia at gmail.com> | Fri Dec 12  
>> 17:12:17 2008 +0200| [21f561ba4af65b0a34ccbc98ed13317c96a96934] |  
>> committer: Rémi Denis-Courmont
>>
>> Added vlc_get_libvlc_object to libvlccore
>>
>> It is intented to expose the libvlc_int_t (the main vlc object)
>> to enable extented vlc hacking.. E.g. when you need to make something
>> with configuration or modules that it is not provided by the PUBLIC  
>> API,
>> you expose the libvlc_int_t as an vlc_object_t and act upon it with
>> the internal (libvlccore) API...
>>
>> Signed-off-by: Rémi Denis-Courmont <rdenis at simphalempin.com>
>>
>> Put back to libvlc rather than libvlccore (a stupid idea of mine).
>>
>
>
> I think your idea was ok :
> the user of this function wants libvlc_int_t to act upon it with
> libvlccore API. In addition the release of this function is done by
> vlc_object_release (libvlccore).
> For these reasons i think it is  more consistent to be exported from
> libvlccore. In my branch i'm already using it within a project in
> linux and windows.

But then you need to link libvlccore with libvlc. That's not wanted...

>
> Of course the user of this API should have all the includes (not just
> the SDK exported ones under include/vlc). But this makes sense cause
> you want libvlccore functions to act upon the object anyway.
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel