275 merging corpora

[kvesik]

User can access merge function via File menu. They can choose to merge one or more existing corpora into either a new file, or into the one that's currently open. The user will have to make decisions about what to do in case the files to be merged contain conflicting EntryIDs or ID-glosses.

[kvesik]

@kchall let me know if there's anything in the GUI or the behaviour that you'd like to change

[kchall]

Looks great, @kvesik !

A couple of requests / issues:

1. If I have tried to merge two corpora with conflicting IDs, and told SLP-AA to cancel if they conflict, then that works. But if I then use the "go back" buttons and change to "create new IDs," and then "continue" forward back to the "merge" screen, it looks like this:

There's nothing overtly wrong with this, but the focus is still on the "Done" button instead of the "Merge corpora" button (because it shifted there when I tried the first merge), so now I run the risk of hitting enter and exiting without merging. Maybe we should still add a warning if the user really tries to click "Done" without having actually completed any merge?

• [x] ask about re-disabling next/done buttons if parameters are changed
• [x] implement fix

2. In the corpora I tried to merge, there were duplicated ID glosses. I chose the option to have SLP-AA update the ID-glosses with numbers. When the corpora are done merging, it automatically shows a list of the duplicated lemmas. Could it also give me a list of duplicated / auto-updated ID-glosses, in case I want to go back and manually change them? (Maybe these would have been listed in the warning box? which is good, but it's easier to copy them from the end-result box, so it would be nice to have them there too.)

   • [x] list duplicated ID-glosses in results window

3. ^The reason for the "duplicated" ID glosses above, though, was that all of them were blank. This seems like a bit of an edge case; could the software ignore identical empty ID glosses?

   • [x] ignore empty ID-glosses

4. Love the checkbox for "Open new merged file" -- but it doesn't seem to always work? At least, when I merged two corpora into a new separate file and had that box checked, then closed the merge dialogue box, I was still on my old corpus. (See 5 below for a case when the button did work, when merging into the current corpus.) Also, maybe the checkbox could say "Open new merged file when this dialogue box is closed" for clarity?

   • [x] investigate buggy behaviour --> Checking the box after the merge is completed works, but if user checks the box first and then clicks the "merge" button then the new corpus doesn't open after the merge wizard is closed.
   • [x] implement fix
   • [x] change wording

5. When I chose the option "Save current corpus and merge into this one," the wizard skipped over the step where I choose the name and location of the file, which makes sense. But, when I clicked in the final step on "Merge corpora," I did then get a system dialogue box in which I was supposed to select the name and location of the file. If I gave it a new name, it proceeded in the same fashion as if I had instead created a new merged file originally. If I gave it the name of the currently open corpus, it warned me that I was overwriting, and then did merge into that existing file. At that point: (1) if "open new merged file" was checked, it did automatically reload the file with the additional items in it when I closed the merge dialogue box, as expected; (2) if "open new merged file" was NOT checked, then when I closed the merge dialogue box, I was still in my original file, without the extra signs. In the case of (2), I could open the same file again and see the merged corpus, or I could just keep working in the still-open corpus and save it and never actually see the results of the merge (because those were in turn overwritten when I saved the still-open corpus).

   • [x] investigate buggy behaviour
   • [x] implement fix

[kvesik]

@kchall can you please take a look at branch 275 again when you have a chance? The merge wizard now:

• checks for unsaved changes to the current corpus before allowing the user to start a merge process
• no longer has a "merge into existing" option
• lists duplicated ID-glosses in the status display window on the last page of the wizard
• ignores empty ID-glosses
• allows user to go back and forth through the wizard pages
  • if they don't change anything, then the contents of all other pages remain the same, and the "next" or "finish" buttons remain enabled/disabled as before
  • if the user changes anything on any page, then the above is also true... EXCEPT on the final page (where you push the button to actually merge), which will have its status display cleared and the "finish" button made unavailable

[kchall]

@kvesik Thanks, Kaili, this all looks good to me! Felt very straightforward and streamlined, and behaved as expected.