Changeset 34205

Timestamp:

2020-06-18T00:06:23+12:00 (4 years ago)

Author:

ak19

Message:

Collection ConfigFileEditor related changes, bugfixes and improvements: 1. In investigating why clientGLI > Edit > collectionConfig.xml > Save button didn't save and get reflected in the interface, found that regular GLI had the same problem. A simple all to c_man.saveCollection() fixed it for GLI, apparently should do so for client-GLI too but still to test. 2. A larger change is to make sure edits in GLI that affect collCfg.xml get saved to collCfg.xml before Edit > collCfg.xml loads the config file. This includes user values entered in controls being edited in the currently selected GLI pane. GLI code gave me a massive run-around to figure how its magic auto-save feature was working but I think I've figured it out now: It's that in GLI Panes which affect colCfg.xml (like Format pane), the loseFocus() on a GLI Pane triggers loseFocus() on GUI controls in that Pane (e.g. Format Pane's General field controls). These controls then save their current values to the collConfig in memory. Then an explicit call to c_man.saveCollection() happens. So just calling c_man.saveCollection before an Edit > collCfg.xml operation won't save the active edits in the current controls of the selected GLI Pane. Based on this understanding, I've forced a loseFocus() on the current pane, to force it to save the current state of its controls, before GLI loads the CollConfigEditor. It works. 3. ConfigFileEditor in GLI (and therefore hopefully in client-GLI too) no longer closes and reopens the collection on saving colcfg edits. This was a quick fix in the past to the problem of getting GLI to immediately reflect changes made to the currently open collection's colcfg.xml file. With the fixes in (1) and (2) this commit is able make a useful improvement to this behaviour, as the changes in this commit avoid having to close and reopen a collection after saving changes in CollConfigEditor, while aiming for the same effect of getting the interface to immediately reflect the edits. Great gains could especially be had with client-GLI, assuming this commit works for it too, as the close then reloading collection operation can take such a long time with client-GLI. Fingers crossed.

Location:

main/trunk/gli/src/org/greenstone/gatherer

Files:

• cdm/CollectionConfiguration.java (modified) (2 diffs)
• cdm/CollectionDesignManager.java (modified) (1 diff)
• collection/CollectionManager.java (modified) (1 diff)
• gui/ConfigFileEditor.java (modified) (3 diffs)
• gui/GUIManager.java (modified) (3 diffs)

main/trunk/gli/src/org/greenstone/gatherer/cdm/CollectionConfiguration.java

@@ -67 +67 @@
     // This method is initilised in CollectionDesignManager.java constructor
     public CollectionConfiguration(File collect_config_file)
-    {
+    {       
+        load(collect_config_file);
+    }
+
+    private void load(File collect_config_file) {
         this.collect_config_file = collect_config_file;
         this.collect_config_filename = collect_config_file.getName();
@@ -84 +88 @@
 
         //XMLTools.printXMLNode(document.getDocumentElement());
+    }
+
+
+    public void reload() {
+        load(this.collect_config_file);
     }
 

main/trunk/gli/src/org/greenstone/gatherer/cdm/CollectionDesignManager.java

@@ -120 +120 @@
     }
 
+
+    public void reloadConfig() {
+    // Parse and load the current collection configuration again
+    // Used after GLI > Edit > collectionConfig.xml > Save to get these edits into GLI.
+    
+    collect_config.reload();
+    if (DebugStream.isDebuggingEnabled()) {
+        collect_config.display();
+    }
+    loadDesignDetails();
+    DebugStream.println("CollectionDesignModule loaded.");
+    }
+
     /** Reloads the various managers to ensure they have built themselves from the latest details available in the collection configuration class
      * @see org.greenstone.gatherer.cdm.ClassifierManager

main/trunk/gli/src/org/greenstone/gatherer/collection/CollectionManager.java

@@ -1303 +1303 @@
     }
 
-
+    
+    public void reloadAfterConfigFileEdited() {
+    // Copying just the part of LoadCollectionInternal below that loads the config file
+    // Need to reload the *existing* config file, however. So calling custom method reloadConfig()
+    
+    // Don't see why this stuff here (vs LoadCollectionInternal) would need to happen in its own
+    // Thread for my use: when the modal Edit > collectionConfig.xml dialog has saved and closed.
+    
+    // reload current collection's config
+    collection.cdm.reloadConfig();
+
+    // We're done. Let everyone know.
+    DebugStream.println(Dictionary.get("CollectionManager.Loading_Successful", collection.getName()));
+    Gatherer.refresh(Gatherer.COLLECTION_OPENED);
+    }
+    
     public void loadCollection(String collection_file_path)
     {

main/trunk/gli/src/org/greenstone/gatherer/gui/ConfigFileEditor.java

@@ -80 +80 @@
     String collection_folder_path = Gatherer.getCollectDirectoryPath();
     String collectionName  = Gatherer.c_man.getCollection().getName(); // we won't be in this constructor if collection is null.
+
+    // Gatherer.c_man.saveCollection(); // on Edit > collectionConfig.xml menu click,
+    // collection save has already happened as GLI pane.lostFocus() got called on current GLI Pane
+    // if/where this affects collectionConfig.xml. For an explanation, see GUIManager.java,
+    // look for "if(esrc == menu_bar.edit_config)"
+
     this.config_file = new File(collection_folder_path + File.separator + collectionName, Utility.CONFIG_GS3_FILE); // col config editing is a GS3 feature
 
@@ -201 +207 @@
     // Final dialog setup & positioning.
     setDefaultCloseOperation(DISPOSE_ON_CLOSE); // get rid of this dialog when it's closed (on dispose())
+    this.addWindowListener(new WindowAdapter() { // called on dispose. Return focus to any curr GLI Pane
+        public void windowClose(WindowEvent we) {
+            Gatherer.g_man.doRegainFocus();
+        }
+        });
+    
+
+    
     getRootPane().setDefaultButton(save_button);
     Dimension screen_size = Configuration.screen_size;
@@ -234 +248 @@
         // close and reopen the collection in GLI
         String current_collection_filepath = Gatherer.c_man.getCollection().getCollectionPath();
-        Gatherer.c_man.closeCollection();
-        Gatherer.c_man.loadCollection(current_collection_filepath);
+        ////Gatherer.c_man.closeCollection(); // explicit save was necessary after all
+                                              // closeCollection() doesn't auto-save
+        ////Gatherer.c_man.loadCollection(current_collection_filepath);
+
+        
+        // Fixing bug: Edit > colcfg wasn't being saved on Save when client-GLI.
+        // And in fact, it wasn't properly saving in GLI for some GLI panes.
+        // That's because save needs to be explicitly called. (Didn't understand how GLI's
+        // "autosave" worked until now. GLI > File > Close a collection saves it, but underneath
+        // it calles SAVEandCloseCollection.
+        
+        // Works - but arduous: have to load in the entire collection just because cfg changed?
+        // Especial pain with client-GLI where reloading takes forever.
+        //Gatherer.g_man.saveThenCloseCurrentCollection();
+        //Gatherer.c_man.loadCollection(current_collection_filepath);
+
+        // Better way: don't have to close and reopen the entire collection after editing colCfg.xml
+        // This just updates GLI's interface with the current collCfg.xml.
+        // Fingers crossed this works for client-GLI, because then the coll won't need to be closed
+        // and reopened each time after Edit > collectionCfg.xml gets saved.
+        Gatherer.c_man.saveCollection(); // should save colcfg whether GLI or client-GLI
+        Gatherer.c_man.reloadAfterConfigFileEdited();
+        //Gatherer.g_man.updateUI(); // didn't do what I hoped it would, so is this relevant here?
+                     // It's done when a new collection is loaded, so may be useful?
+                     // But all my tests concerning GLI > Edit > collConfig.xml worked out without it
+        
     }
     

main/trunk/gli/src/org/greenstone/gatherer/gui/GUIManager.java

@@ -148 +148 @@
     }
 
-
+    
     public void windowLostFocus(WindowEvent e)
     {
@@ -266 +266 @@
     else if(esrc == menu_bar.edit_config) {    
         if(Gatherer.c_man.getCollection() != null) {
-
+        // Before we open the current collection's collectionConfig.xml for editing,
+        // need to make sure any presently unsaved edits are saved into collConfig
+        // so they are reflected in this config file when loaded into the editor for editing.
+        // A simple Gatherer.c_man.saveCollection() is not sufficient: it won't save ongoing
+        // edits in the currently selected GLI Pane (where relevant to colcfg)
+        
+        // Whenever a user swaps from one GLI pane to another, loseFocus() is called on the pane
+        // and for some GLI Panes, this triggers a collection save, but notably also triggers a
+        // loseFocus() on the pane's editing fields/controls, which saves any ongoing mods in that
+        // pane to the collectionConfiguration file.
+        // - See loseFocus() of BaseConfigPane.java (that only SOME gli Pane's inherit from)
+        // and also apparent in GUIManager.windowLostFocus().
+        // - And for implementations of Control.loseFocus(), see for example via
+        // CollectionManager.loadDesignDetails() -> GeneralManager (for Format > General tab)
+        // which leads to GeneralManager.loseFocus() which gets "Called to store the current
+        // value of the components" - of its Controls. Exactly the behaviour we want!
+        
+        // Not all GLI Panes inherit from BaseConfigPane, but then, not all GLI Panes
+        // make changes to the collection Config file; e.g. the Gather pane makes changes to 
+        // the file system, Enrich makes changes to metadata.xml files and *.mds metadata sets
+        // files. But Design and Format panes make changes to collectionConfig.xml.
+        // In theory Create pane ought to as well, e.g. can set import options which also exists
+        // as ImportOptions in collectionConfig.xml, but they're not linked (yet) and Create pane
+        // doesn't inherit from BaseConfigPane. CreatePane's loseFocus() also don't call
+        // for the the collection to be saved.
+
+        // What all this means is that when we prepare to open the collectionConfig.xml,
+        // we want a collection save but want also the current state of GLI edits to be saved
+        // into collConfig before we display the collConfig file for editing.
+        // To trigger this behaviour we want to call loseFocus() on the current pane, called
+        // "previous_pane". That method may or may not force a save to collConfig,
+        // depending on whether it is warranted for that pane, but in such cases it will also
+        // cascade the loseFocus() call to the controls in that pane, who will save their current
+        // values into the colcfg in memory before this gets saved to the colCfg.xml file.  
+        
+        if(previous_pane != null) {
+            doLoseFocus();
+        } 
+        //Gatherer.c_man.saveCollection(); //shouldn't have to do this, in theory. See above comment
+        
         ConfigFileEditor configEditor = new ConfigFileEditor();
         configEditor.setVisible(true);
@@ -1035 +1074 @@
     }
 
-
+    // Want to triger loseFocus() on GLI Panes at will when Menu > Edit > collectionConfig.xml clicked.
+    // And when done editing, want to trigger doRegainFocs().
+    // loseFocus() on GLI Panes is not universally inherited from a common base class
+    // But loseFocus() is important as it forces saves as-is of user entered values in gui fields
+    // When alling doLoseFocus() on GLI > Edit > collConfig.xml, we force a save of the current state
+    // of the current pane (called "previous_pane").
+    // Else a save is only triggered when another GLI Pane is clicked. We can't expect a user to
+    // remember to click other panes whenever they want to edit the collConfig.xml.    
+    private void doLoseFocus() {
+    
+    if (previous_pane != null) {
+        if (previous_pane == gather_pane) {
+        gather_pane.loseFocus();
+        }
+        else if (previous_pane == enrich_pane) {
+        enrich_pane.loseFocus();
+        }
+        else if (previous_pane == design_pane) {
+        design_pane.loseFocus();
+        }
+        else if (previous_pane == create_pane) {
+        create_pane.loseFocus();
+        }
+        else if (previous_pane == format_pane) {
+        format_pane.loseFocus();
+        }
+    }
+    }
+    public void doRegainFocus() {
+    
+    if (previous_pane != null) {
+        if (previous_pane == gather_pane) {
+        gather_pane.gainFocus();
+        }
+        else if (previous_pane == enrich_pane) {
+        enrich_pane.gainFocus();
+        }
+        else if (previous_pane == design_pane) {
+        design_pane.gainFocus();
+        }
+        else if (previous_pane == create_pane) {
+        create_pane.gainFocus();
+        }
+        else if (previous_pane == format_pane) {
+        format_pane.gainFocus();
+        }
+    }
+    }
+    
     /** Any implementation of ChangeListener must include this method so we can be informed when the state of one of the registered objects changes. In this case we are listening to view changes within the tabbed pane.
      * @param event A ChangeEvent containing information about the event that fired this call.