GSoC 2020: Tree Model - Week 10
Last week's update:
I added Tuplets and Spanners (ties, slurs, etc.) to the treeWrite() function and tried to reduce the diff with the previous code as much as I can, and here's what I ended up with.
So most of the file is matching now (about 80% of the lines are matching now), but still there are a lot of differences in the format.
To get it to this state I have only implemented the treeWrite() function in 7 functions and made a list of properties to be written for 27 elements.
However, the problem is, if I want it to match 100%, I will have to override treeWrite() in a lot more places, and then the code would become as complex as it was before. This is because most write() functions have a lot of if/else statements and there is essential complexity in the format itself, so it must go somewhere in the code. The basic point of refactoring is to simplify the code, so if it isn't getting simpler then the refactoring won't be as useful.
So I discussed this issue with my mentor, and in the end we decided that I'll be changing my plan, and now I'll be trying something else instead. So here's the new plan ;-)
The plan ahead:
So in the last two-three weeks of GSoC, I'll be trying to replace the ScoreView with a QAbstractItemView. This was actually the basic idea for introducing the tree model (which is a QAbstractItemModel) in the first place.
Later on, perhaps after my GSoC, I or someone else may be able to continue with the treeWrite function that I had started implementing. Till then the normal write functions work anyway. But converting the ScoreView to a QAbstractItemView will be something new, and In the end, this might lead to better accessibility features (like screenreader support and keyboard navigation). So I'm quite excited to try this out and I will keep you updated through these blog posts :)
Links
Previous Blog: https://musescore.org/en/user/1743616/blog/2020/08/04/gsoc-2020-tree-mo…
Next Blog: https://musescore.org/en/user/1743616/blog/2020/08/17/gsoc-2020-tree-mo…