Fix grip size (replicate MU3 behaviour) and make it easier to select grips

[cbjeukendrup]

Resolves: #9257

Despite my comment there, I replicated the MU3 behaviour (which was in fact already done, but guiScaling was not taken into account).

Also, below a grip, there might be elements that do not belong to that grip. When clicking the grip at the location of such an element, that element would get selected rather than the grip. That was frustrating and made it difficult to grab the grip.
I changed that: now, when you click anywhere inside a grip's rectangle, you will be selecting the grip, instead of the unrelated element below it.
(When you still want to select the element below it, just click outside the grip, or click somewhere on the canvas to unselect the element to which the grip belongs, so that the grip disappears.)

[Jojo-Schmitz]

I take that something liks eht 1sdt commit might be needed for 3.x as well?
I've found 2 places in the 3.x code that might need this:

MuseScore/mscore/editelement.cpp

Lines 39 to 54 in 2513676

	void ScoreView::updateGrips()
	{
	if (!editData.element)
	return;
	double dx = 1.5 / _matrix.m11();
	double dy = 1.5 / _matrix.m22();
	for (const QRectF& r : editData.grip)
	score()->addRefresh(r.adjusted(-dx, -dy, dx, dy));
	qreal w = 8.0 / _matrix.m11();
	qreal h = 8.0 / _matrix.m22();
	QRectF r(-w*.5, -h*.5, w, h);
	editData.grip.resize(editData.grips);

and

MuseScore/mscore/fotomode.cpp

Lines 150 to 155 in 2513676

	void ScoreView::endFotoDrag()
	{
	qreal w = 8.0 / _matrix.m11();
	qreal h = 8.0 / _matrix.m22();
	QRectF r(-w*.5, -h*.5, w, h);
	editData.grip.resize(8);

In either case width and height muliplied by guiScaling?

[cbjeukendrup]

@Jojo-Schmitz I don't think it's necessary in MU3, in the first place because it just works as is (don't fix it if it ain't broken 😉).

In the second place, I think that the guiScaling is somehow handled by the scaling of the painter in MU3. In MU4, there is a lot of multiplying and dividing with that guiScaling, and I suspect that this shouldn't be necessary. I will research that in the future.

Anyway, I see that you added it already to your 3.7 PR, so I will try how it works out in the artifact.

[Jojo-Schmitz]

Yes, please try and tell me. I don't have a HighDPI screen to test this on
If it isn't needed there, it is easily removed again ;-)

[cbjeukendrup]

I think it should be removed from the MU3 PR. The result is that the grips are too big when they appear, and when zooming using the trackpad, they jump back to the correct size.

[Jojo-Schmitz]

OK, will do

Edit: done. Thanks for checking. Seems I missunderstood the title, "(replicate MU3 behaviour)" to mean that the same issue exists there too

[DmitryArefiev]

Checked #9257 on Mac11 - FIXED

In Dorico, the grips follow the zoom level, which looks and works a lot better in my opinion. We could also do that, and >maybe set a minimum and maximum size, so that they don't get too small at smaller zoom levels or too big at higher zoom >levels.

Noticed that too.. Will log it as a separate issue