Finish cleaning up libvlc

Most important is playlist. Plus probably a bit of cleanup in audio and video

Discussion on http://wiki.videolan.org/index.php/MediaControlAPI

assigned to @zorglub

Could possibly be delayed until test1. I don't have much time working on this atm

(In [14149]) Play and add (Refs:#457 (closed))

(In [14190]) * get/set/toggle fullscreen

• Fix a bug in playlist_play

(Refs:#457 (closed))

VLM won't be included in 0.8.5.

Littlejohn has quite a good chunk of code for libvlc and wrapping of mediacontrol, according to wiki plan, waiting for him (he has some connection problems)

changed milestone to %0.8.5-test3

changed milestone to %0.8.6

changed the description

changed title from External APIs rework to Finish cleaning up libvlc

added Severity::major label

Currently there's a lack of functions to access playlist elements data, such as inputs title and so on.

I'm working on this

(In [18416]) A bit of cleanup in libvlc playlist API. Preliminary work for: Refs:#457 (closed)

unassigned @zorglub

Status and plans?

Now that libvlc is a shared library, we have to keep the API stable. Whatever you have done or not yet done, you'd better we do it before the 0.9.0 release... nobody wants to delay a release because of the API.

Past 0.9.0 release, adding APIs is fine, but suppressing or modifying existing ones (including public structs) will NOT be tolerable because of this :(

Also the libvlc-control/libvlc split disagreement needs to be resolved. Stuff that links against libvlc-control MUST NOT depend on libvlc directly; if it does, the split is essentially useless: the only point of libvlc-control is to shield bindings from the less stable for-plugin libvlc.

I don't think any of the current functions in the API will be deleted nor modified, but for sure new functions will be added in the future. 0.9.0 release will not be affected by libvlc-control status.

libvlc-control depends for a few calls on libvlc. To solve this issue a refactoring of libvlc/libvlc-control is needed. This said, I don't see the dependency of libvlc-control to libvlc as an error or a problem. libvlc-control offers a cleaner and more stable api to developers and bindings, which is the aim of its creation.

libvlc-control must of course depend on libvlc. That's not the point. But anything that depend upon libvlc-control MUST NOT depend on libvlc directly. Otherwise the split is COMPLETELY POINTLESS. This means that whatever links against libvlc-control MUST NOT link against libvlc directly.

AFAIK during compile and link time, libvlc is not needed on the target. I checked on libjvlc, and it is linked only against libvlc-control.

(In [18900]) * Start cleaning up libvlc playlist API (Refs:#457 (closed))

• Return correct item ids
• Structures for navigating the playlist
• Consistent locking

• Add a b_locked parameter to the remaining playlist API calls

What is the status of this cleaning now ?

assigned to @pdherbemont

Looks clean enough to me. We may just want to disable the function marked deprecated.

changed milestone to %0.9.0-TP

[fun@kebab ~/vlc]% grep -rni obsolete|deprecated include/vlc src/control [fun@kebab ~/vlc]%

?

added Status::fixed label

closed

mentioned in issue #19926 (closed)