Symbols can no longer swap their places in the palettes

• Jan 7, 2019 - 15:20
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Many
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.1.4922, revision: 598057d

1) Default score
2) Check you are in custom workspace and with enable editing
3) Try to swap place of symbols eg in Articulations palette (same result in all palettes)

Result: failure. Symbols are sticked in their cell
(you can add and delete them only)

Comments

• Jan 7, 2019 - 15:46
Title Symbols can't no longer swap their place in the palettes ⇒ Symbols can no longer swap their places in the palettes

I remember a discussion on this, but I can't find a duplicate issue.

Reply

• Jun 21, 2019 - 16:15

At least it would be nice to have a comment from a developer to try to understand what's going on. What exactly is the problem, what is its difficulty in solving it?
It's a bug that directly hinders the user in each action of organizing his palettes. Personally, I have seen much more "wicked" issues dealt with in a timely manner. However, here, since it has not been resolved for six months, it gives the impression of an issue that is at least as dangerous / difficult/ structural.

Reply

• Jun 21, 2019 - 17:06

You're telling me about the container (redesign). I'm talking about content (and the "simple" ability to move an element within it, as it was always possible since the version 2.x)

Reply

• Jun 21, 2019 - 17:31

I did take a look at this but the reasons why it doesn't work seem tied up in aspects of input processing I don't fully understand. I do not feel confident that I would be able to fix it myself without risking breaking something else. It's also the sort of thing that may well be dependent on Qt version and OS to some extent, and this will call for more extensive testing. I could be totally wrong about that, though - again, this is not an area of the code I am very comfortable with. But I'm not giving up, on attempting to deal with this myself, or in trying to get others who do know this code better to do so.

FWIW, the GSoC work is indeed relevant here. It's not just about how they are displayed, but how they process input, and my understanding is that it will be a pretty large-scale redesign of the internal structure of palettes and the code associated with it. I think mike320 is correct to observe that there is a certain reluctance to invest much time in code that is in the process of being completely rewritten.

I suspect it's also the case that palette customization is seen as a pretty "advanced" feature and we've been so focused on getting the basics right. I do feel like we got almost all the way there for 3.1, although since then the focus has mostly been on dealing with the regressions introduced by the many changes for 3.1, and the upcoming 3.2 (!) should put us in pretty good position there.

Meanwhile, the workarounds remain, drag into a new palette, or edit the palette file by hand. I've done both of the above when I've needed this.

Reply

• Jun 21, 2019 - 17:38

Ok, Marc, full explanation appreciated. But frankly, the workaround is just bad; imagine creating new diagrams (it is not "a pretty "advanced" feature", it's quite a basic one), and sort them by series of chord names, C / D / E and others, it's just a pain, you have no rights to the error.

Reply

• Jun 21, 2019 - 19:01

On further investigation, see the issue #283590: Default palettes should not be able to rearrange in Mac which is mentioned earlier in this thread. Apparently, on macOS at least, and perhaps on Linux, it is possible to rearrange palettes by holding Shift while dragging - maybe not in 3.1, but in some 3.0 versions. I realized this as I examined the code and saw places where we tried to do something for this, but also saw where we did something that prevented it from working - on Windows, at least. I can't actually see how it was working any time recently, so again, I suspect there may be some OS and Qt version dependency here. It may depend on the order in which we process events when the mouse leaves one cell and enters another.

Anyhow, the bottom line is that it seems there was a deliberate change here, to make it so Shift would be the way to rearrange palettes, but as mentioned, it doesn't necessarily work right now:

https://github.com/musescore/MuseScore/commit/292a8d9cd139fe3cf373007ea…

I can force it to work by commenting out the code in Palette::leaveEvent(), but I'm afraid of what bad effects that might have.

The way it works, BTW, is a bit different than in 2.3.2. Basically, it doesn't wait for you to release the mouse before moving the element - it just keeps moving the element from cell to cell as you drag. It was a little disorienting at first because it's so fast, but maybe ultimately it's a better way of working.

Reply

• Jun 22, 2019 - 00:22

Sure, sorry I forgot to add the necessary flag to make this available to begin with. Here is the build:

https://ci.appveyor.com/api/buildjobs/j5o15l6rv03r8ab8/artifacts/MuseSc…

Remember, you need Shift while dragging, and the behavior is different than 2.3.2, so it takes a minute to get used to. This change was quite deliberate and went into effect a few years back but may or may not have ever worked on Windows. With this fix, it should work as it was intended to.

After playing with it a bit, I think I could believe I like it better. Even if I didn't, changing it to work as it did before would be much more than the one-line change I made here and definitely not anything I'd expect to see done for the current palette implementation. But it could certainly be considered for the rewrite that is in progress, if the consensus is that the old method was better.

Reply

• Jun 22, 2019 - 00:59

After a first try, and add-delete-rearrange of fretboard diagrams, it works just fine here. Well, it's about time! Thanks!
For my part (and my opinion/feeling after testing), I have any problem by using the Shift key in addition.

We already do Ctrl + Shift + drag to drop an element into the palette.
If you have to do Shift + drag this element within the palette, it remains consistent. Just know it and document it (incidentally, as it has never worked under version 3 for the moment, we only have to learn it, once and for all)

Reply

• Jun 22, 2019 - 01:05

I did testing before Marc submitted the PR and I found a minor bug on my system that results from ctrl+click the item you want to add to the palette then ctrl+shift+drag the item to the palette as normal. Marc cannot reproduce this bug so the question is, "Does any one else see the bug?" If the bug is going to be ignored (which I'm fine with until after GSoC is done), then I'm in favor of this PR being merged, though I'd be surprised to see it in 3.2 which is in its final stages before release.

Reply

• Jun 22, 2019 - 01:21

I don't see this by combining Ctrl + click then Ctrl + Shift + drag.
BTW, I see no reason not to include it in 3.2 next week. Obviously, we have to make sure that there is no unexpected effect this weekend.
Moreover, I do not think you are the most concerned by this issue. Guitarists, all guitarists are, and completely, that's for sure, (just read the differents comments on this thread), and this, since the very first version 3, more than six months. A straw!

Reply

• Jun 22, 2019 - 01:27

The reason I was the first to comment on this was because I found the problem about the same time as you and was not at all happy. This is a feature I very much want to see back. I forgot that today is Friday, but 3.2 was released on the weekend if I remember correctly and the release builds are in the works if I understand discussions I've seen on telegram.

Reply

• Jun 22, 2019 - 03:04

Indeed, the plan as I understand it is that the most recent build from yesterday will become 3.2 if no showstopper bugs are found. And I do support that plan, because really there were some pretty serious regressions in 3.1 that we really need to fix ASAP. So this fix, if approved, would probably have to wait until 3.2.1, which, hopefully won't be too much longer. Meanwhile, of course, you can use the build I provided (or a nightly if/when it is merged for the master branch) to customize palettes all you like, then save them and load them into 3.2. A slightly better workaround than the others, maybe, depending on how often you rearrange your palettes (I probably do this no more than once a month, but guitarists may well do it more often).

As far as testing goes, I can be extremely specific about what to test, because the change is equally specific: it only affects what happens when the mouse leaves a palette cell while Shift is pressed. Previously, we would forget everything about the cell you just left. Now, we remember which cell you were in so we know which palette element to move. Absolutely nothing else is affected except this. But, it's important to test the various different scenarios where you might be moving the mouse out of a palette cell with Shift pressed:

1) deliberately rearranging the palette with Shift+drag (obviously)
2) if you happen to have pressed Shift while just moving the mouse around the palette
3) if you have used the palette search facility and are browsing the results with Up & Down keys
4) if you are adding a new element to the palette with Ctrl+Shift+drag, and you happen to pass through multiple palette cells on the way
5) etc.

Any time the mouse cursor leaves a palette cell with Shift pressed, my change takes effect - I can't currently distinguish these different scenarios. My guess is whatever bad effectmike320 saw in testing, it was due to case 4). But I can't actually make anything bad happen.

Reply

Fix version
3.2.1