Why not replace, the same way hard-deleting barlines has replaced the menu command to merge measures? And parts can be reordered in 2.0.3. in the dialog.
Ah, yes, forgot that it is in 2.0.3 too. Having the up/down buttons there additionaly may make sense, as that's where you shuffle them during creation. And I don't see any good reason to remove them
The reason might be the extra work of updating that list to match the actual order of the dragged tabs.
As to "that's where you shuffle them during creation"—yes, of course, because at present that's the only way to do it. But it's wildly inefficient. To move a part tab from last to first may require dozens of mouse clicks, compared to closing the dialog and then dragging the tab along in one motion. The latter method seems so much more preferable that I don't think anyone would wish for the former.
For me, the only time I'd be likely to do this is if I have a mostly completed piece (hence have already generated parts), and then I decide to add an instrument somewhere in the middle. The moment I see MuseScore add it to the end - while still in the dialog - is when I'd love it up. This works nicely now. No way would I want to give that up and be forced to drag tabs around after the fact. I'm happy to see that ability added to handle *other* use cases, but for mine, the existing model is better.
IMHO the +/- buttons in the parts dialog are good while initially creating or adding parts, being able to move the Tabs is nice and intuitive to reshuffle existing parts, so I'd like to see both.
My assumption is that the list in the dialog is built anew from the current part list each time the dialog is opened, so the right things should happen automatically. If some some odd reaosn this isn't the case, well then it should be :-)
Not really. If you drag a tab, the order in the dialog does not update; if you then change the order of the list in the dialog, the actual tab order does update.
And for some strange reason this dragging tabs doesn't work in master (aea3845) anymore. And not in 2.1-RC either.
Only using dialog's up/down buttons works
Oops, sorry, for Tabs of linked parts this hadn't been implemented.
reading this issue history, I got a little chuckle reading Jojo's comment #8:
Looks simple and innocent enough to make it into 2.0.4 too?
lol, since we now knew it managed to produce a crash! (I'm not laughing at you jojo, just laughing at how simple things can produce crashes).
Anyway, I'm reading the above disccusion about whether to allow Excerpt Tabs to be rearranged. I noticed Issac's comment #20
I tried adding the same line of code to "tab2." It makes the part tabs very nicely draggable. But the list in File -> Parts does NOT stay in sync.
I would agree that it would be nice to rearrange excerpts tabs by dragging. It seems that the File->Parts list could be easily kept in sync by making sure to handle the tabMoved signal such that it updates the part list. Although maybe too risky for 2.1, but maybe I'll make PR for 3.0.
Unfortunately https://doc.qt.io/qt-5/qtabbar.html has the "movable" boolean apply to the entire QTabBar...so there isn't a way to set all tabs except the first tab to be movable. So I don't know of an easy way to implement movable excerpt tabs while preventing the first tab (the main score) from moving. It may be simplest to simply not implement this feature for excepts.
Re: movable QTabBar or QTabWidget set some tabs fixed
I think you could handle the QTabBar::tabBarClicked() signal. If the index of the tab that is clicked is one that you do not want to be movable, then set movable to false in the slot, otherwise set it to true. You should also handle the QTabBar::tabMoved() signal, and set movable to false there. You should start out with movable set to false.
This might not work if the tabBarClicked() signal is only emitted on an actual click (mouse down then up).
Although that seems like a bunch of extra code...might not be worth it.
Actually the method I copied in #32 has a flaw: it would still permit user to click on a child score's tab and then move it to the left of the parent score. I can't think of a simple way to prohibit that.
That is in addition to the flaw they already describe whereby a mouse click event is different from a mouse press event.
I was also brainstorming another possible alternative solution, which would be to have the seconday tab only contain child scores, while the primary tab only contains main score...so for instance the tab layout would be modified like:
In which case pressing on the primary tab would select parent scores, while pressing on secondary tabs would select child scores only. So pressing a parent tab would setCurrentIndex(-1) for the secondary tab (so that no secondary tab is selected). But anyway, that is food for thought I'm just bringing up as a possible way to go. I actually think it would make more logical sense, since the tab hierarchy would represent the score hierarchy. But anyway, that would clearly not be for 2.1, but might be something to consider for 3.0...
It occurred to me if do what I describe in #34, then if have the split view, would probably want to be able to keep the child tab order in sync across the other ScoreTab when move the tabs around on one. This is because there should only be one ordering of child scores for a particular score.
Comments
This would be useful.
I guess Qt either supports this or it doesn't.
Shortcut for switching tabs would be nice too.
Please implement it. Another solution could be to move "Up" and "Down" the parts in the "Parts Dialog". It's not possible at the moment...
I definitely would like that, too. See also #60521: Add shortcut for switching between parts in a score and #59986: [Mac] Ctrl+Tab to switch between scores does not work.
came up again in https://musescore.org/de/node/126391
Fixed in branch master, commit 202d3728f8
fix #8954: Move Tabs Around
Looks simple and innocent enough to make it into 2.0.4 too?
Fixed in branch 2.0.4, commit 4be4113e5d
fix #8954: Move Tabs Around
That was easy! :)
Can this be applied to the tabs for linked parts, too, replacing the up/down arrows in the Parts dialog?
Not replace but accompany. And probably for 3.0 only, as only that has the infrastructure for moving parts?
Why not replace, the same way hard-deleting barlines has replaced the menu command to merge measures? And parts can be reordered in 2.0.3. in the dialog.
Ah, yes, forgot that it is in 2.0.3 too. Having the up/down buttons there additionaly may make sense, as that's where you shuffle them during creation. And I don't see any good reason to remove them
The reason might be the extra work of updating that list to match the actual order of the dragged tabs.
As to "that's where you shuffle them during creation"—yes, of course, because at present that's the only way to do it. But it's wildly inefficient. To move a part tab from last to first may require dozens of mouse clicks, compared to closing the dialog and then dragging the tab along in one motion. The latter method seems so much more preferable that I don't think anyone would wish for the former.
For me, the only time I'd be likely to do this is if I have a mostly completed piece (hence have already generated parts), and then I decide to add an instrument somewhere in the middle. The moment I see MuseScore add it to the end - while still in the dialog - is when I'd love it up. This works nicely now. No way would I want to give that up and be forced to drag tabs around after the fact. I'm happy to see that ability added to handle *other* use cases, but for mine, the existing model is better.
Also from an accessibility standpoint, drag and drop is never acceptable as there inky way of doing something.
IMHO the +/- buttons in the parts dialog are good while initially creating or adding parts, being able to move the Tabs is nice and intuitive to reshuffle existing parts, so I'd like to see both.
Okay. Important to keep them in sync, though.
My assumption is that the list in the dialog is built anew from the current part list each time the dialog is opened, so the right things should happen automatically. If some some odd reaosn this isn't the case, well then it should be :-)
I tried adding the same line of code to "tab2." It makes the part tabs very nicely draggable. But the list in File -> Parts does NOT stay in sync.
Does anything bad happen as a result?
Not really. If you drag a tab, the order in the dialog does not update; if you then change the order of the list in the dialog, the actual tab order does update.
Automatically closed -- issue fixed for 2 weeks with no activity.
Using this feature causes a crash: #190991: Scores get each other's titles on first edit after reordering tabs, crash on close
And for some strange reason this dragging tabs doesn't work in master (aea3845) anymore. And not in 2.1-RC either.
Only using dialog's up/down buttons works
Oops, sorry, for Tabs of linked parts this hadn't been implemented.
I believed I fixed Issac's bug report #190991: Scores get each other's titles on first edit after reordering tabs, crash on close with https://github.com/musescore/MuseScore/pull/3150
Basically the scoreList order needs to be updated when the tabMoved signal is produced...very straightforward fix.
reading this issue history, I got a little chuckle reading Jojo's comment #8:
lol, since we now knew it managed to produce a crash! (I'm not laughing at you jojo, just laughing at how simple things can produce crashes).
Anyway, I'm reading the above disccusion about whether to allow Excerpt Tabs to be rearranged. I noticed Issac's comment #20
I would agree that it would be nice to rearrange excerpts tabs by dragging. It seems that the File->Parts list could be easily kept in sync by making sure to handle the tabMoved signal such that it updates the part list. Although maybe too risky for 2.1, but maybe I'll make PR for 3.0.
Yep, I found that funny too ;-)
Would like the parts dragging in 2.1 though, now that we know how it is to be done, right?
Ok, jojo, I'll go ahead and make the fix for *excerpt* tabs for for 2.1...I'll just append it as a commit to my previous PR.
Just making a note: although allow Score Excerts to be moved around, I suppose still should prevent the main (parent) score to be moved from index 0.
Unfortunately https://doc.qt.io/qt-5/qtabbar.html has the "movable" boolean apply to the entire QTabBar...so there isn't a way to set all tabs except the first tab to be movable. So I don't know of an easy way to implement movable excerpt tabs while preventing the first tab (the main score) from moving. It may be simplest to simply not implement this feature for excepts.
Well there is one way to do this: http://www.qtcentre.org/threads/60887-movable-QTabBar-or-QTabWidget-set…
Although that seems like a bunch of extra code...might not be worth it.
Actually the method I copied in #32 has a flaw: it would still permit user to click on a child score's tab and then move it to the left of the parent score. I can't think of a simple way to prohibit that.
That is in addition to the flaw they already describe whereby a mouse click event is different from a mouse press event.
I was also brainstorming another possible alternative solution, which would be to have the seconday tab only contain child scores, while the primary tab only contains main score...so for instance the tab layout would be modified like:
![tab-view-currently.png]( "tab-view-currently.png")
In which case pressing on the primary tab would select parent scores, while pressing on secondary tabs would select child scores only. So pressing a parent tab would setCurrentIndex(-1) for the secondary tab (so that no secondary tab is selected). But anyway, that is food for thought I'm just bringing up as a possible way to go. I actually think it would make more logical sense, since the tab hierarchy would represent the score hierarchy. But anyway, that would clearly not be for 2.1, but might be something to consider for 3.0...
It occurred to me if do what I describe in #34, then if have the split view, would probably want to be able to keep the child tab order in sync across the other ScoreTab when move the tabs around on one. This is because there should only be one ordering of child scores for a particular score.
I'm going to close this issue because I have fixed #190991: Scores get each other's titles on first edit after reordering tabs, crash on close for 2.1 and master.
I've filed feature request #192726: Remove duplicated tab for main score & enable setMovable (to allow reordering of parts) based on what I described in #34, so please comment on that there.
I meant to set this to "fixed" instead of "closed".
Automatically closed -- issue fixed for 2 weeks with no activity.