[pydocs] don't add core code comments to pydocs

diff --git a/xbmc/interfaces/legacy/Control.h b/xbmc/interfaces/legacy/Control.h
index 9b4bdfe..26a5630 100644 (file)
--- a/xbmc/interfaces/legacy/Control.h
+++ b/xbmc/interfaces/legacy/Control.h
@@ -41,38 +41,37 @@ namespace XBMCAddon
   namespace xbmcgui
   {
 
-    /**
-     * Parent for control classes. The problem here is that Python uses 
-     * references to this class in a dynamic typing way. For example,
-     * you will find this type of python code frequently:
-     *
-     * window.getControl( 100 ).setLabel( "Stupid Dynamic Type")
-     *
-     * Notice that the 'getControl' call returns a 'Control' object.
-     * In a dynamically typed language, the subsequent call to setLabel
-     * works if the specific type of control has the method. The script
-     * writer is often in a position to know more than the code about
-     * the specific Control type (in the example, that control id 100
-     * is a 'ControlLabel') where the C++ code is not.
-     *
-     * SWIG doesn't support this type of dynamic typing. The 'Control'
-     * wrapper that's returned will wrap a ControlLabel but will not
-     * have the 'setLabel' method on it. The only way to handle this is
-     * to add all possible subclass methods to the parent class. This is
-     * ugly but the alternative is nearly as ugly. It's particularly ugly
-     * here because the majority of the methods are unique to the 
-     * particular subclass.
-     *
-     * If anyone thinks they have a solution then let me know. The alternative
-     * would be to have a set of 'getContol' methods, each one coresponding
-     * to a type so that the downcast can be done in the native code. IOW
-     * rather than a simple 'getControl' there would be a 'getControlLabel',
-     * 'getControlRadioButton', 'getControlButton', etc.
-     *
-     * TODO:This later solution should be implemented for future scripting 
-     * languages while the former will remain as deprecated functionality 
-     * for Python. 
-     */
+    // Parent for control classes. The problem here is that Python uses 
+    // references to this class in a dynamic typing way. For example,
+    // you will find this type of python code frequently:
+    //
+    // window.getControl( 100 ).setLabel( "Stupid Dynamic Type")
+    //
+    // Notice that the 'getControl' call returns a 'Control' object.
+    // In a dynamically typed language, the subsequent call to setLabel
+    // works if the specific type of control has the method. The script
+    // writer is often in a position to know more than the code about
+    // the specific Control type (in the example, that control id 100
+    // is a 'ControlLabel') where the C++ code is not.
+    //
+    // SWIG doesn't support this type of dynamic typing. The 'Control'
+    // wrapper that's returned will wrap a ControlLabel but will not
+    // have the 'setLabel' method on it. The only way to handle this is
+    // to add all possible subclass methods to the parent class. This is
+    // ugly but the alternative is nearly as ugly. It's particularly ugly
+    // here because the majority of the methods are unique to the 
+    // particular subclass.
+    //
+    // If anyone thinks they have a solution then let me know. The alternative
+    // would be to have a set of 'getContol' methods, each one coresponding
+    // to a type so that the downcast can be done in the native code. IOW
+    // rather than a simple 'getControl' there would be a 'getControlLabel',
+    // 'getControlRadioButton', 'getControlButton', etc.
+    //
+    // TODO:This later solution should be implemented for future scripting 
+    // languages while the former will remain as deprecated functionality 
+    // for Python. 
+    //
     // We don't need the SWIGHIDDENVIRTUAL since this is not a director.
     class Control : public AddonClass
     {

diff --git a/xbmc/interfaces/legacy/Player.h b/xbmc/interfaces/legacy/Player.h
index 289ff99..41aa949 100644 (file)
--- a/xbmc/interfaces/legacy/Player.h
+++ b/xbmc/interfaces/legacy/Player.h
@@ -49,12 +49,13 @@ namespace XBMCAddon
      *          - xbmc.PLAYER_CORE_DVDPLAYER
      *          - xbmc.PLAYER_CORE_MPLAYER
      *          - xbmc.PLAYER_CORE_PAPLAYER
-     *
-     * This class is a merge of what was previously in xbmcmodule/player.h
-     *  and xbmcmodule/PythonPlayer.h without the python references. The
-     *  queuing and handling of asynchronous callbacks is done internal to
-     *  this class.
      */
+
+    // This class is a merge of what was previously in xbmcmodule/player.h
+    //  and xbmcmodule/PythonPlayer.h without the python references. The
+    //  queuing and handling of asynchronous callbacks is done internal to
+    //  this class.
+
     class Player : public AddonCallback, public IPlayerCallback
     {
     private:

diff --git a/xbmc/interfaces/legacy/WindowXML.h b/xbmc/interfaces/legacy/WindowXML.h
index 0f9bd8a..8b9c2c8 100644 (file)
--- a/xbmc/interfaces/legacy/WindowXML.h
+++ b/xbmc/interfaces/legacy/WindowXML.h
@@ -115,21 +115,20 @@ namespace XBMCAddon
 #endif
     };
 
-    /**
-     * Ideally what we want here is a Dialog/Media Window. The problem is that these
-     *  are two orthogonal discriminations of CGUIWindow and there wasn't a previous
-     *  accounting for this possibility through the use of making CGUIWindow a 
-     *  virtual base class of the pertinent subclasses. So now we're left with
-     *  no good solution.
-     *
-     * <strike>So here we're going to have the 'main' hierarchy (the one visible to SWIG)
-     *  go the way intended - through WindowXML, but we're going to borrow dialog 
-     *  functionality from CGUIDialog by using it as a Mixin.</strike>
-     *
-     * jmarshall says that this class has no reason to inherit from CGUIMediaWindow.
-     *  At some point this entire hierarchy needs to be reworked. The XML handling
-     *  routines should be put in a mixin.
-     */
+    // Ideally what we want here is a Dialog/Media Window. The problem is that these
+    //  are two orthogonal discriminations of CGUIWindow and there wasn't a previous
+    //  accounting for this possibility through the use of making CGUIWindow a 
+    //  virtual base class of the pertinent subclasses. So now we're left with
+    //  no good solution.
+    //
+    // <strike>So here we're going to have the 'main' hierarchy (the one visible to SWIG)
+    //  go the way intended - through WindowXML, but we're going to borrow dialog 
+    //  functionality from CGUIDialog by using it as a Mixin.</strike>
+    //
+    // jmarshall says that this class has no reason to inherit from CGUIMediaWindow.
+    //  At some point this entire hierarchy needs to be reworked. The XML handling
+    //  routines should be put in a mixin.
+
     class WindowXMLDialog : public WindowXML, private WindowDialogMixin
     {
     public: