GSoC 2019 : Week 2 - TreeView with a model using QAbstractItemModel

Posted 4 years ago

This blog post provides a brief report on the work I have done in the second week in the coding period of the Google Summer of Code program

Work Planned to be Done:

  1. Construct a model using a QAbstractItemModel.
  2. Make a Resource file to handle the data provided to make a treeView resembling a Palette.
  3. Construct a Model using the .xml file containing all the Palette Items.

Work Done:

Construction of a TreeView with a model using the QAbstractItemModel.

I created the model using the QAbstractItemModel as mentioned on the previous blog since QStandardItemModel will not provide the logic for each of the palette Items and also due to its flexibility. Here, I used a .txt file as the data for the model and made certain changes in the way in which the treeView is displayed.

pal.png

Started making a treeView along with the Palette Box.

I finally started writing the code for the treeView in the Palette Box. Unfortunately, I couldn’t make the model from the .xml (Musescore/share/workspaces/Basic.cpp) file yet. I have learned how the XML parser works and soon I will be implementing the treeView with the data provided in the .xml file as the model.

Currently, I am working on the treeView to be constructed on the Palette Box with a sample text file as a data for the model, later I will code for the treeView using the .xml file as the data for the model, which will need the class XmlReader.

Comments

• Jun 11, 2019 - 21:17

> Work Planned [...] 3. Construct a Model using the .xml file containing all the Palette Items.

That might have been your plan but I certainly never expected you to get that far in one week. ;)

> Currently, I am working on the treeView to be constructed on the Palette Box with a sample text file as a data for the model, later I will code for the treeView using the .xml file as the data for the model, which will need the class XmlReader.

I'm not sure if this was written before or after our discussion earlier, but now that you know how the model works I suggest you try to create it in MuseScore. Once that is done you can return to the example project to implement a right-click menu (and probably some buttons for people who don't like using a mouse). Once you know how to do that in your example project you can try it in MuseScore... and so on.

This is the best way to do things because:

  1. You experiment outside of MuseScore.
    • MuseScore takes ages to compile, so working on a small example is much faster.
    • You see how things should be done rather than how they are currently done in MuseScore.
    • Your code is modular, so it can be used in any part of MuseScore rather than just the palettes.
  2. But you always take what you have learned and add it to MuseScore straight away.
    • This means you always have something to show if the project ends early for some reason.
    • (If you carried on experimenting you might run out of time before you start adding things to MuseScore.)

Reply