GSoC 2018: Score Comparison Tool — Week 9

Posted 5 years ago

Hello!

This week after fixing some issues of the developed score comparison engine (mostly concerning spanners handling) I have started a work on a graphical interface for the score comparison tool. Currently its look is far from perfect but to some extent it works. Below is the screenshot of MuseScore with the new tool launched, as it looks at the moment (full resolution):
Screenshot_20180716_023050.png

During the next week I will improve the interface of the tool — hopefully to some useful state. Then I will probably work on improving both the tool interface and the score comparison engine. Though this plan seems to be applicable for the next few weeks. Anyway I hope to be able to show the tool in its better state next week!

I have also some questions regarding design of the score comparison tool. These questions as well as more detailed description of the planned tool design and possibilities can be found here: thread, questions post.

Thanks,
Dmitri Ovodok


Comments

Looks very good! Make sure you give each item/widget an accessible name (equal to the displayed text) and accessible description. Consider using a screen reader to test the UI for accessibility support (see guide). This will encourage you to think about how the controls relate to each other, as well as helping users with special accessibility needs.

In reply to by shoogle

The screenshot is a bit outdated, I have already switched to drop-down lists for choosing scores. The chosen element switches if user switches to another tab but it is possible to choose any score from those are currently open. Screenshot_20180718_132253.png

Concerning accessible name, Qt doc says it is necessary only for widgets that do not provide any displayed text as otherwise Qt will use this displayed text if accessibleName is not provided. Of course, it is not difficult to duplicate the text in accessibleName property but will it have any effect?

In reply to by dmitrio95

Good point. If the screen reader can get the name from the text in the widget then you don't need to set one manually, but you should test it to make sure. You'll still need to give a name to the dropdowns ("Score 1" and "Score 2") and the diff widget ("Diff view", or similar).

For now, I would say it looks very good. Already quite usable.

I am wondering, can this work be extended in the future to enable a fully graphical diff tool, like MS Word's "track changes" function. Obviously, that would be a lot of work and outside of the scope of the GSOC project, but I think your work lays a good foundation for such functionality to be implemented in the future. I think that would be a very powerful tool for teaching or collaborative composition.

In reply to by Louis Cloete

Thank you!

I don't use MS Word but I guess I understand what do you mean :) Yes, a possibility to compare scores makes it possible to track also changes between different versions of the same score (though I think there are also other ways to solve this problem), but it will probably indeed be outside the scope of my GSoC project. I will focus first on improving a score comparison engine and on a creation of the textual tool with some limited visual features like jumping to the relevant positions in the compared scores on diff item selection. But in the future such a feature may possibly become real!

In reply to by dmitrio95

The gist of the "Track Changes" function in MS Word (and LibreOffice! Find it under Edit->Track Changes.) is that any text you delete or change gets changed to another colour and striked through and any text you insert gets changed to another colour and underlined. In MuseScore, I envision a similar function, but when I started thinking about how to implement it, I got stuck. It is a bit more difficult than doing it on text. But anyway, I realise it is definitely outside the scope of your project. I was just curious if your code can be used as the basis an implementation of something like this later on.