Bug 111570

The reason the rest are listed is because they are cached (a sort of fly-weight pattern implementation).  We could remove the unused files from the combobox but I still want to keep them around in memory for performance reasons.

Interesting. That problem also bugged me in the past, and I definitely second Matthew's suggestion to remove them from the list. Now, I have a question about the caching: what exactly is cached ? What would happen if I do the following:
- load a few vectors from file1.dat
- change the vectors to be read from file2.dat
- modify file1.dat (possibly including some changes to the list of fields, or reduction of number of samples)
- try to read vectors from file1.dat again.
Will the field list and sample numbers be updated correctly ?

Perhaps we should reconsider this... some data sources (eg, ascii) can keep a 
fair amount of data around....  Maybe a 'purge files' type option?

> The reason the rest are listed is because they are cached (a sort of
> fly-weight pattern implementation).  We could remove the unused files from
> the combobox but I still want to keep them around in memory for performance
> reasons.

SVN commit 465477 by arwalker:

BUG:111570 The change data file dialog will only contain that files that are actually in use, whereas previously it showed all files.

 M  +8 -4      kstchangefiledialog_i.cpp  


--- trunk/extragear/graphics/kst/kst/kstchangefiledialog_i.cpp #465476:465477
@@ -69,15 +69,17 @@
 void KstChangeFileDialogI::updateChangeFileDialog() {
   KstRVectorList rvl = kstObjectSubList<KstVector,KstRVector>(KST::vectorList);
   KstRMatrixList rml = kstObjectSubList<KstMatrix,KstRMatrix>(KST::matrixList);
-
+  QMap<QString, QString> filesUsed;
+  int i;
+  
   // clear list
   ChangeFileCurveList->clear();
   
   // first add vectors
-  int i;
   for (i = 0; i < (int)rvl.count(); i++) {
     rvl[i]->readLock();
     ChangeFileCurveList->insertItem(rvl[i]->tagName());
+    filesUsed.insert(rvl[i]->filename(), rvl[i]->filename()); 
     rvl[i]->readUnlock();
   }
   
@@ -85,6 +87,7 @@
   for (i = 0; i < (int)rml.count(); i++) {
     rml[i]->readLock();
     ChangeFileCurveList->insertItem(rml[i]->tagName());
+    filesUsed.insert(rml[i]->filename(), rml[i]->filename()); 
     rml[i]->readUnlock();  
   } 
 
@@ -96,9 +99,10 @@
   _files->clear();
   KstReadLocker ml(&KST::dataSourceList.lock());
   for (KstDataSourceList::Iterator it = KST::dataSourceList.begin(); it != KST::dataSourceList.end(); ++it) {
-    _files->insertItem((*it)->fileName());
+    if (filesUsed.contains((*it)->fileName())) {
+      _files->insertItem((*it)->fileName());
+    }
   }
-
   if (_files->contains(currentFile)) {
     _files->setCurrentText(currentFile);
   }

  There's another interesting side effect from this.  Now it's impossible to 
change file and then change back unless you leave at least one vector using 
that file.  This isn't a useful case?

George, I don't quite understand your point. Changing back should always be possible, it is not different from changing the data file in the first place. But sure, when there is someday a Undo/Redo framework, this kind of operation (changing data file) should be included in the list of revertable actions :-)

  Yes ignore that last comment. :-)  No-one would try to do what I was 
thinking.