I made BtTreeItem::Type a strongly-typed enum (ie used enum class instead of just enum). This tells the compiler to do stricter checking about what you're doing with the enum, rather than just treating it as an int. So, eg, it finds places where you've got a switch statement that doesn't handle all values of the enum, etc. It also means you have to refer to BtTreeItem::Type::FOLDER rather than BtTreeItem::FOLDER, so you don't have to worry so much about names from different enums clashing with each other.
I templated some functions that shared a lot of code, eg BtTreeItem::recipe(), BtTreeItem::equipment(), etc become BtTreeItem::getData<Recipe>(), BtTreeItem::getData<Equipment>(), etc.
In BtTreeModel::dropMimeData(), when the target is a folder, I added a call to folderChanged() so that the change of folder shows up straight away in the GUI.
In BtTreeModel::deleteSelected(), when deleting a folder, I changed the order of the deletes so that the contents of the folder are dealt with before the folder. (The folder itself has no underlying existence in our object model, but removing it from the GUI model, ie BtTreeModel, before its contents invalidates the QModelIndex values for those content items.)
A couple of changes here:
BtTreeItem::Typea strongly-typed enum (ie usedenum classinstead of justenum). This tells the compiler to do stricter checking about what you're doing with the enum, rather than just treating it as an int. So, eg, it finds places where you've got a switch statement that doesn't handle all values of the enum, etc. It also means you have to refer toBtTreeItem::Type::FOLDERrather thanBtTreeItem::FOLDER, so you don't have to worry so much about names from different enums clashing with each other.BtTreeItem::recipe(),BtTreeItem::equipment(), etc becomeBtTreeItem::getData<Recipe>(),BtTreeItem::getData<Equipment>(), etc.BtTreeModel::dropMimeData(), when the target is a folder, I added a call tofolderChanged()so that the change of folder shows up straight away in the GUI.BtTreeModel::deleteSelected(), when deleting a folder, I changed the order of the deletes so that the contents of the folder are dealt with before the folder. (The folder itself has no underlying existence in our object model, but removing it from the GUI model, ieBtTreeModel, before its contents invalidates theQModelIndexvalues for those content items.)