Reordering parts with new part moves wrong part, and other problems with Parts dialog

• Dec 7, 2015 - 03:34
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

To reproduce, in any score with existing parts, go to File -> Parts…, click New, check an instrument on the right, and then use the Up/Down arrows to move the new part (named "Part") up through the list. Click OK. Result: the part that moved was not "Part"), but whatever was last on the list before "Part" was created.

Comments

• Dec 13, 2015 - 17:22

I looked at this issue. No easy way to solve it. The problem is that the ordering happens in the qml dialog in the excerptList. At first, this list is the same as score->excerpts()

But if we add new part, score->excerpts() isn't updated before we accept the changes in the dialog, so references get mixed up.

In fact, the actual implementation of the Parts dialog is a bit strange. If we delete a part, the tabs in the score is immediately updated and deleted ( score->excerpts()), but if we add new parts, they are created only when we click the Ok button. Btw, there is also a "flicker" of the parts of dialog when a part is deleted.

First, this makes ordering the parts impossible. New parts are always created at the end of the list.

Second, the behavior should be standard : either we allow the user to make all the changes he wants, then apply them we he clicks the OK button. Or remove the OK button and make all the changes immediately effective.

From my point of view, making the changes immediately effective would be easier to implement (i.e. for the ordering), but I think it'd be better for the user to avoid any changes until the user validates the dialog with OK.

Any thoughts on this?

Reply

• Dec 13, 2015 - 22:18

I will say that I've noticed the inconsistency between adding and deleting parts—especially that "Cancel" has the same effect as "OK" in the case of deleting a part.

Reply

• Dec 14, 2015 - 03:02

Yeah, because the real deletion happens right after we click the delete button.

And there are issues with the undo because of all this behavior.

So the questions we'd need answer to update the Parts dialog behavior :

- Should all actions (delete, add, reorder) be executed right after we click the action button, or should all of them be effective only when we click the Ok button?

- Second thing related to the previous one. After we close the Parts dialog, how should we manage the Undo action? Should all specific actions (delete, add, reorder) be executed separately (in reverse order the user entered them), or should all the Parts dialog action be considered a single whole undo action?

Reply

• Dec 14, 2015 - 20:29
Title Reordering parts with new part moves wrong part ⇒ Reordering parts with new part moves wrong part, and other problems with Parts dialog

- It would be by far preferable to not apply any changes until "OK" is clicked, thus allowing the "Cancel" option.

- I kind of think it would be preferable for "Undo" to undo everything that was just "OK"-ed at once, but I can see why the alternative might make sense, too.

Reply

• Dec 15, 2015 - 21:45

Ah, I wish I could build from source! They haven't been merging pull requests for the past few weeks, so I don't know when I'll get the chance to try the nightly build.

Reply

• Dec 17, 2015 - 16:18

Wow, that's very kind of you—totally unnecessary, but very kind. Thank you.

For what it's worth, I've just started to download twelve gigabytes' worth of QT libraries and I'll see if I can work out how to compile myself. ;-)

Reply

• Dec 17, 2015 - 16:27

I was experimenting with methods to incorporate user patches (PR's) into the master code base to test PR's. I had a method I was using a few months ago, but switched to using branches in GIT and wanted to test it out. At the least I now know how to work with branches and the procedure to pull in PR code and revert easily, so not a loss for me at all!

Reply

• Dec 17, 2015 - 17:57

Those two bottom lines are not at all self explanatory for branch management, esp for those unfamiliar with GIT. I am still working on expanding that section.

Reply

• Dec 18, 2015 - 16:13

Wow! Again, all I can say is thank you for being so kind. I am happy to confirm that your fix seems to work excellently in all ways. ;-)

Reply

• Jan 12, 2016 - 22:11

I wonder why PR aren't merged anymore...
I'm merging PR again and looking to this one right now. To answer your implied question, from time to time we need to focus on MuseScore.com or on the MuseScore mobile apps and so we are not able to review and merge PRs.

Reply

• Jan 12, 2016 - 22:17

I meant something more along the lines of "I wasn't worried, and you don't need to worry about us worrying," or something like that—but never mind. The point was just to acknowledge receipt of your message.

Reply