diff options
author | tpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da> | 2010-02-17 00:54:13 +0000 |
---|---|---|
committer | tpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da> | 2010-02-17 00:54:13 +0000 |
commit | 092be7678b67552cb3161fe162242bf8d3aeed2f (patch) | |
tree | be0693f45b101252c370e40f6e84da2cd7a52f75 /src/DESIGN.txt | |
download | kmplayer-092be7678b67552cb3161fe162242bf8d3aeed2f.tar.gz kmplayer-092be7678b67552cb3161fe162242bf8d3aeed2f.zip |
Added old abandoned KDE3 version of kmplayer
git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/applications/kmplayer@1091557 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
Diffstat (limited to 'src/DESIGN.txt')
-rw-r--r-- | src/DESIGN.txt | 38 |
1 files changed, 38 insertions, 0 deletions
diff --git a/src/DESIGN.txt b/src/DESIGN.txt new file mode 100644 index 0000000..e0e3a31 --- /dev/null +++ b/src/DESIGN.txt @@ -0,0 +1,38 @@ +The core of kmplayer is in kmplayerpartbase.x. PartBase keeps +the list of Source objects (dvd/vcd/url/..) and Process objects +(mplayer/xine/gst/xv), controls the View or respond to its signals. Both +application as kpart (for plugin) have one PartBase. However, in case of +plugin for khtml, it's possible one PartBase controls multible View +objects (see tests/controls.html). + +The View is the parent of ViewArea, PlayList and InfoWindow. ViewArea is +the parent of Viewer (the output for the backend players) and +ControlPanel. +In case of smil animations, the Viewer widget can be hidden or made +smaller so ViewArea background is where the rendering is done. +Classes in kmplayerplaylist.x are actually base for the XML playlist +formats (smil/asx/rss/..). + +There is always one Source object active. A Source object sets up the +interface to the user as far possible, handling playlists and launching +backends. This is not fully worked out yet, eg. URLSource should be able +to launch multible backends for smil. Which probably means that PartBase +should have a list of Process factories and Source objects a list of +running Process objects. + +Backends are instances of Process and should be simple, just passing +data from/to external processes. A Recorder object is also a Process. +Though for mplayer, there is quite some code for output parsing. + +The XML classes and parser provide a quick way for storing any XML file +in the playlist. Tree nodes build the tree themselves and recognized +multimedia elements more or less play the playlist themselves too. +The parser is build to recover from all kinds of typos. This is because +ASX is quite often full of XML errors that made other parsers give up, +eg. I've seen something like "<Title>Laurel & Hardy< / title>". + +KMPlayerPart and KMPlayerApp are classes that use the above for plugin +and application. + +Finally there is also a Settings class for general usage and for +launching the configure dialog. |