Remove duplicated tab for main score & enable setMovable (to allow reordering of parts)
Since #8954: Move Tabs Around has been fixed, I would now like to allow user to reorder each parts tab by clicking and dragging on them.
However, we cannot simply make the parts tab movable, because that would allow user to move a part before the main score, and unfortunately Qt does not have an easy way to prohibit a particular tab from being reordered. But I've proposed an alternative workable solution to remove the main score tab from the secondary tab, like:
in which case pressing on a Parent Score tab on top would display the main score in the scoreView, and would also deselect any selected tab for child tab using setCurrentIndex(-1).
Note to implementer: if have split view, will need to keep child scores tabs synced, like I did with https://github.com/musescore/MuseScore/commit/dd7fbe26571dc0c157c6c3847…
Comments
Why is it so desirable to prevent users from moving a part tab to the left of the score if he really wants to?
@Marc, if user moved a part to the left of the main score tab, I personally find it undesirable because the main score is superior to the part scores. Now maybe you or others don't find that undesirable, which I can understand. The first time I made parts, I personally found it confusing that the main score was displayed with equal footing as the part scores, when really it is the top of a hierarchy.
Also, I would find confusion about where Exports Parts should place the main score in ...Score_and_Parts.pdf. Should the main score appear in the same order according to the order of tabs?
Also I want to enable setTabsClosable for the child scores, but since I'm saying the semantics of closing a child tab means that that part is deleted from the score, then that semantic wouldn't apply when closing the main score child tab.That is a little confusing to me and would mean that I would have to forgo the feature of deleting child tabs by closing them, so users would have to go to File parts to delete specific parts.(Off-topic: I just had an idea of adding a context menu to main tabs or child tabs if right click on parent tab or anywhere on the child QTabBox, which would allow user to immediate create parts without going to File->Parts. I've filed this as #192886: Right Click context menu for ScoreTab to add & delete parts)
I'm editing this issue based on feedback from Jojo and kuwitt which I'm sortof feeling like agreeing with which basically says having an X in the tab to delete a part is problematic because semantics of X usually just means to close something.
If you personally find it undesirable have a part to the left of the score, then don't move it there in your own scores. I don't see why we need to redesign the interface to prevent others from doing so if they personally choose to. I can think of a number of perfectly valid reasons to want to do this. If disallowing it could be done without causing confusion I might not be concerned - after all, it's not like they can move the part before the score now either. But I think your proposed implementation will lead to lots of questions about how to get back to the score after viewing a part, from people accustomed to the current method. Is it really worth it just to prevent people from doing something they might want to but you personally wouldn't take advantage of?
I have to agree with Marc on this one. Even though I wouldn't normally want to move a part to the left of the score, I can see reason for doing so. If someone has a score with more parts than will fit across the screen they may want to move the score to the right so they can easily switch between a part and the score without having to scroll (using the arrows) to see the other one. This will keep them from having to move parts out of order to accomplish the same thing.
For the record, I'm fine with allowing tabs to be movable before the main score tab, even though I personally don't like the main tab to be on the same level as the child tabs.
The only reason why I used the word personally is because I cannot speak for anyone else because it is a subjective view and not something which can be held objectively true, since it is merely a stylistic preference.
I still want to know the answer to my question regarding export to Score_and_Parts: where should the main score should be if it is not the first tab? Should it appear in the same order as the tabs, or should the main score always appear first, regardless of where it is in the tab order.
Cool. The only good reason I see to force the score to the left is to avoid weirdness with synchronizing the order ot tabs with the order of parts in File / Parts.
As for the export, I think score first or last makes most sense regardless of tab order. In fact, to me there are two possibly different orders for parts - the one you want to see on screen, which could be based on what you happen to be working on at the time, and what you want for print/export, which is probably "score order".
Another suggestion: make all the tabs for the individual parts be movable, but have a button marked "Score" at the left of the second tab bar.
@Isaac, do you mean instead of the score title? I'm not sure this is best but I could be wrong. This makes it clear which score you are looking at parts for. I realize the selected score is a slightly different shade than the others. I don't know if this will cause problems for some people with vision problems or not. Thoughts?
@Mike, yes, like this:
![Screen Shot 2017-04-25 at 5.01.49 PM.png]( "Screen Shot 2017-04-25 at 5.01.49 PM.png")
The current tab is not only a different shade from the others, it's also slightly larger ("closer") and visually connected to what appears below it. I don't think duplicating the title again is necessary, any more than it is in, say, MuseScore's Preferences.
I like Issac's suggestion #10 and mockup in #12. I personally would use to word "Full Score" so it is unambiguously clear what it refers to (since "Score" in the context of MuseScore could refer to a part as well). Being labeled as such and being a button separate from the rest of the children ensures that the parent score doesn't get reordered with the children, and makes it clear to user that can't drag the tab before the button since the QTabBar and QButton are clearly separate layout objects.