[vlc-devel] [RFC] Playlists

Boris Dorès babal at via.ecp.fr
Thu Jan 23 00:23:01 CET 2003


  We will talk in this mail about playlists and related items in the
VLC. But first, a more general consideration: there is far too much
code in the interfaces, which makes so hard to maintain and debug a
dozen of them. Interfaces should call a far more developped set of
functions and wrappers in the vlc core so that each call to something
else than its own graphical management doesn't take more than a line (in
a perfect world of course). That way, we should avoid code duplication
in the various interfaces, and they should be easier to maintain, not
to mention the fact that VLC should have the same behaviour on all
plateforms, which isn't the case at this time for instance with playlist
management.


So now let's talk about our main subject: playlists
___________________________________________________

  VLC playlist management needs a bit of work in order to be as
efficient as in other players. We also need to take into account modules
such as SAP, SLP, or VLCS clients which need to automatically add some
items to the playlist: it's indeed very frustrating for instance to see
some items pop up in the playlist again and again, even if we deleted
them, because such modules continuously regenerate the playlist content.

  Available channel list
  ______________________

  First of all, we should distinguish the main "playlist", which would
remain roughly the same as it is currently (except for a bunch of
features we'll discuss later), from a list of all available channels,
automatically generated by modules such as SAP, SLP or VLCS.

  Each module which needs to add such items should create a private
channel list. It could this way freely insert its own items into it
without disturbing other modules. Then, all it would have to do is to
register that list to the playlist management core, and unregister it
when the module is unloaded. The playlist management core would then
generate a list of all available channels simply by merging all those
independant lists and eliminating duplicated MRL, in order to expose
that clean content to the interfaces.

  Main playlist management core features
  ______________________________________

  The main playlist could then remain approximately the way it is
currently, but we should add a lot of new features to get a more user
friendly behaviour.

- first of all, we should be able to save it as a file; the most
  reasonable way is to save it in a standard format (the code for m3u
  format is almost done), so that it does not affect the "open" process
  which already exists (it would just need a few adjustments, see next
  point).

- there should be two separate sets of commands in the playlist window:
  - one to add a file (or a saved playlist) to the current playlist
  - one to open a playlist (which in this case replaces the current
    one) or a file (which replaces the current playlist with a new one
    containing only the opened file)

- when opening a file (or a playlist) from the main window, depending on
  the global variable "enqueue to playlist", it should either replace
  the current playlist or be enqueued.

- there should be a menu or a dialog box both in the main window and in
  the playlist window to open or add (as described before) an item from
  the "available channel list"

- of course there should be the possibility to drag and drop an item
  to the main interface or to the playlist dialog box, but it's only a
  shortcut to the open dialog boxes, with the same behaviour that has
  been described before.

- we should implement (properly I mean) the already existing
  configuration options: auto-delete an item when played,
  enqueue/replace, play at random, play reverse.

- finally, the playlist management core should expose some functions to
  sort the playlist on various fields, and also to move items manually
  according to user's will.

  How input modules open a playlist
  _________________________________

  To restore a playlist from a file, the input demuxer creates a new
playlist and registers it to the playlist management core. The latter
then decides to add the playlist or to replace the current one depending
on the behaviour described before (this procedure is compatible with the
old input, even if it would of course greatly benefit from the new one).

  Last open files and preferred playlists
  _______________________________________

  In the open menus, we should find two "submenus" (the exact
representation is to be decided on an interface basis, we describe it
here only for clarity):

- one listing the last N opened playlists and files

- one listing permanently all the playlists saved in a "favorite
  playlists" folder to allow direct access to them (this feature is
  found for instance in Windows Media Player with the concept of
  Multimedia Library which stores permanently the user playlists)

  At first, this point seems to concern the interface rather than
the playlist management core. However, due to our first general
consideration, the associated code should be implemented in the core,
and only used in the interface.


  We are now waiting for your comments on this RFC before starting
coding it.

-- 
Lool, Fenrir, Ipkiss and Babal
-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>



More information about the vlc-devel mailing list