summaryrefslogtreecommitdiffstats
path: root/src/DESIGN.txt
diff options
context:
space:
mode:
authortpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2010-02-17 00:54:13 +0000
committertpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2010-02-17 00:54:13 +0000
commit092be7678b67552cb3161fe162242bf8d3aeed2f (patch)
treebe0693f45b101252c370e40f6e84da2cd7a52f75 /src/DESIGN.txt
downloadkmplayer-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.txt38
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.