the big modules changes

[Samuel Hocevar]

   I am about to commit quite a few changes in the way modules work, and
as usual most module files will need to be changed. People currently
working on a module will 1.) hate me, and 2.) need to resolve a few
conflicts.

   There are two important changes in the way modules work:

    * a module now only has one capability, which is a string, allowing
      arbitrary capabilities vlc isn't even aware of.

      Example: vlc shouldn't have to worry about ac3_adec's downmix, only
      the ac3_adec plugin knows how to request a downmix module.

    * a module can have submodules, which lets have several capabilities
      in a single module, like before.

      Example: the sdl plugin has "video output" and "audio output"
      submodules.

   In the process I would also like to clean the mess in the plugins/
directory, which is becoming hard to follow. I will tune the Makefile
so that it can build modules deeper in the tree, and I suggest the
following layout:

   modules +-> audio +-> output -> dsp alsa arts ...
           |         +-> mixer -> ...
           |         `-> filter -> ...
           +-> video +-> output -> x11, ggi, glide, ...
           |         +-> chroma -> i420_rgb, i420_yuy2, ...
           |         `-> filter -> transform, deinterlace, ...
           +-> access +-> file, network, ...
           |          +-> vcd
                      `-> dvd -> dvd, dvdread, dvdplay, ...
           +-> demux -> mpeg, mp4, ...
           +-> codec +-> mpeg +-> audio -> adec, mad
           |         |        `-> video -> vdec
           |         +-> a52 -> a52dec 
           |         `-> ffmpeg
           +-> interface -> qt, gtk, kde, ...
           `-> arch -> macosx, qnx, beos, win32, ...

   One annoying issue: since CVS sucks raw eggs through a very thin
straw when moving or renaming files (don't you even dare mentioning
directories!), this will make it hard to access a file's previous
versions.

   Well, my opinion is that we don't really care, VLC is becoming better
and better, there are few situations where old code is really important,
and if someone really needs a previous version, he should have the
skills to get it from its previous location in the tree. I'd be all for
using a more modern tool such as SVN, but it's still a bit early.

   Comments anyone?

Regards,
-- 
Sam.

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