Move Tabs Around

• Jan 30, 2011 - 01:28
Reported version
2.1
Type
Functional
Severity
S5 - Suggestion
Status
closed
Project

Could we implement the ability to move score tabs around?


Comments

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...

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 :-)

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.

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.

Well there is one way to do this: http://www.qtcentre.org/threads/60887-movable-QTabBar-or-QTabWidget-set…

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:
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.