From kde-commits  Fri Dec 30 10:40:24 2011
From: Christian Esken <esken () kde ! org>
Date: Fri, 30 Dec 2011 10:40:24 +0000
To: kde-commits
Subject: KDE/kdemultimedia/kmix
Message-Id: <20111230104024.68E43AC7DB () svn ! kde ! org>
X-MARC-Message: https://marc.info/?l=kde-commits&m=132524176713089

SVN commit 1270921 by esken:

comments only

 M  +1 -1      apps/kmix.cpp  
 M  +1 -0      backends/mixer_backend.cpp  
 M  +2 -2      backends/mixer_backend.h  


--- trunk/KDE/kdemultimedia/kmix/apps/kmix.cpp #1270920:1270921
@@ -782,7 +782,7 @@
     if ( kmw ) {
         kmw->saveConfig( KGlobal::config().data() );  // -<- This alone is not enough, as I need to save the META information as well. Thus use saveViewConfig() below
         m_wsMixers->removeTab(idx);
-        m_wsMixers->setTabsClosable(!kmw->mixer()->isDynamic() && m_wsMixers->count() > 1);
+        m_wsMixers->setTabsClosable(!kmw->mixer()->isDynamic() && m_wsMixers->count() > 1); // This does not work properly in (experimental) multi-driver-mode
 
         saveViewConfig();
 
--- trunk/KDE/kdemultimedia/kmix/backends/mixer_backend.cpp #1270920:1270921
@@ -160,6 +160,7 @@
 		// This code path is entered on Mixer::OK_UNCHANGED and ERROR
 		if ( !_fastPollingEndsAt.isNull() )
 		{
+			// Fast polling is currently active
 			if( _fastPollingEndsAt < QTime::currentTime () )
 			{
 				kDebug() << "End fast polling";
--- trunk/KDE/kdemultimedia/kmix/backends/mixer_backend.h #1270920:1270921
@@ -121,13 +121,13 @@
 
   /******************************************************************************************
    * Please don't access the next vars from the Mixer class (even though Mixer is a friend).
-   * There are proper accesor methods for them.
+   * There are proper access methods for them.
    ******************************************************************************************/
   bool m_isOpen;
   // The MixDevice that would qualify best as MasterDevice (according to the taste of the Backend developer)
   MixDevice* m_recommendedMaster;
    // The Mixer is stored her only for one reason: The backend creates the MixDevice's, and it has shown
-   // that it is helpful if the MixDevice's know their correspondig Mixer. KMix lived 10 years without that,
+   // that it is helpful if the MixDevice's know their corresponding Mixer. KMix lived 10 years without that,
    // but just believe me. It's *really* better, for example, you can put controls of different soundcards in
    // one View. That is very cool! Also the MDW doesn't need to store the Mixer any longer (MDW is a GUI element,
    // so that was 'wrong' anyhow