GSOC 2020: Tree Model - Week 2 (Tree model nearly complete!)

Posted 1 year ago

Hello again!

Here’s what I did last week:

Last time I had planned that I will be adding most of the elements to the score tree model. So to do that first I needed to make a complete hierarchy of all the elements.

So, I went through all the scanElement functions in the libmscore/ folder and made a rough diagram of what all elements they pass through.

Here is the diagram:


The green lines in the diagram show an inheritance relationship between the classes (instead of the parent/child relationship). It means, for example, that a Measure has its children Segments by itself but it also has some extra children which it inherits from MeasureBase. The blue circles show a generic list of Element* pointers, whose types are not known at compile time. The red ones (MStaff and SysStaff) do not inherit from ScoreElement so they can be excluded from the tree. The dotted lines show a kind of indirect connection, like here for example Score::scanElements() uses Pages to get to systems but only calls scanElements on systems.


This diagram contains almost all the visual elements in the score because the scanElements function is used to draw the elements on the screen.

So once I made this diagram I started implementing the treeChild functions. I created a new file called scoretree.cpp, and added these all classes and their children, mostly in the same way as the scanElements function. However, I have made Measure the child of System rather than Score as shown in this diagram. I connected Score -> Page -> System and removed the indirect connection. I moved all the functions to a single file so that it will be easy to see the score hierarchy from top to bottom. I also fixed some crashes in the debugger.

Now the tree debugger shows almost all the elements, like Brackets, Lyrics, Glissandos, Beams, even the staff lines.

There is just a bit of an issue left with spanner elements, because sometimes they are attached to the system and sometimes with some element in the staff. So I’ll just have to handle these two cases separately and I think I’ll be able to fix it soon.

Work to be done this week:

Now I think that the first milestone of my project is close to being complete (adding treeChild functions to each element). I will just clean up the code in my PR and mark it “Ready for review” and I think it can be merged soon since it doesn't affect any existing functionality. I will make the tree debugger show up only in the debug builds and add a menu item for it in the debug menu.

Then I can start working on refactoring some old code based on the tree model. I can perhaps start by refactoring scanElements, that would be the easiest because the tree model is already based on scanElements. After that, I can start working on the score file write/read code.


Pull request on GitHub:
Previous Blog:…
Next Blog:…