modellist: work around filtered item models getting out of sync

[cebtenzzre]

I have yet to understand exactly why, but since #2086 the "Clone" button on the models page sometimes results in the entire settings page being replaced with blank values instead of a cloned model.

I now know that when the "Clone" button is clicked, the id returned fromModelList::clone is not found in the combo box for selection, which leads to index=-1 -> selected value=undefined -> default-constructed ModelInfo() when values are accessed.

This stems from the fact that m_selectableModels doesn't contain the newly added model by the end of ModelList::clone. For whatever reason, the initial ModelList::addModel call does fire an InstalledModels::filterAcceptsRow check on the cloned model, but the ModelList::updateModel call to set its data (which does call ModelList::dataChanged) does not. So m_selectableModels incorrectly thinks the cloned model is not yet "installed."

This PR works around that by explicitly invalidating all of the filter models at the end of ModelList::updateData. In the future, we should figure out why the dataChanged signal does not result in the expected update of the child models.

---

🚀	This description was created by Ellipsis for commit f3f598a

Summary:

Fixes issue with 'Clone' button resulting in blank values by invalidating filter models in ModelList::updateData.

Key points:

• Issue: 'Clone' button on models page sometimes results in blank values on settings page.
• Root Cause: m_selectableModels does not contain the newly added model by the end of ModelList::clone.
• Fix: Explicitly invalidate filter models (m_selectableModels, m_installedModels, m_downloadableModels) at the end of ModelList::updateData.
• Files Affected: gpt4all-chat/modellist.cpp.
• Functions Affected: ModelList::updateData.

---

Generated with ❤️ by ellipsis.dev