Tour dialogs overlap with the highlighted area

• Oct 26, 2018 - 09:22
Reported version
P2 - Medium
S4 - Minor

Since the recent time MuseScore has welcome tours explaining basics of MuseScore usage to new users. This is done by showing informative dialogs while highlighting the relevant area of MuseScore window. However dialogs are places sometimes not correctly overlapping with the selected area. It would be better if they do not overlap, and perhaps it was intended so.
Screenshot from:
OS: Debian GNU/Linux 9 (stretch), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: de93ba1


As I recall (as the person who mentored this project), the placement of these dialogs is a bit system-dependent. For me on Windows, the dialogs are placed better than shown above - that particular tour text shows just below the file toolbar. My recollection is that there were particular problems if the default placement of the dialog caused it to extend offscreen, and the workaround chosen for that may have led to overlap in other cases?

BTW, the same tours included thus far are just that - samples. Likely most them will be replaced before release. But it would indeed be nice if the algorithms for placement worked better across all systems.

In reply to by Anatoly-os

Looking at the screenshot, it looks as if the message box placement differed from windows and linux. In this code snippit:… , it decides where to place the message box; specifically, it decides where it should go if the message box is located above or below the highlighted items.

The "hack" (which I wish I had explained in the comment) adds the height of the title bar -- the part that says "Tour". As you can see, it is only added if the message box will be displayed above the highlighted items. On my machine and supposedly Marc's as well, the message box placement is decided by the top left point of the message box frame. In the screenshot, it is decided by the top left of the message box's contents.

My code uses the message box's size: . It says it "excludes any window frame." By how it looks, it seems to be acting differently on macOS than on windows or linux. I can't say for certain since I'm only looking at it (and I don't have a mac), but I think that may be where the issue is.

EDIT: A good check would be to open the timeline and begin that tour, as it should try to display the message box above the highlighted items. If there is an overlap or a space between the message box and the highlight, that should confirm my suspicions.

SECOND EDIT: Shoot! I didn't see the OS. Ignore the talk about macOS above, but I think the problem is probably still in the same area.

Yes, it seems that the issue is indeed in the tour window's borders. Here is another screenshot displaying a tour for a palette, there is also an overlap in the dialog's border:
Tour for a timeline indeed has some gap between the dialog window and the highlighted area:

A note I made in telegram:

I'm looking at and I think that the solution instead of using a "hack" value of 15 would involve using the functions that include the window frame: "Including the window frame: x(), y(), frameGeometry(), pos(), and move()" that way would hopefully work well across different OSes which possibly use different window frames.

It says "Excluding the window frame: geometry(), width(), height(), rect(), and size()." And so rather than use width() and height() as the current code does, maybe use those other functions.

that PR doesn't seem to work...I'll comment with a gif output.

Anyway, I'm noticing on my Arch Linux machine running Mate desktop that the values of mbox->frameGeometry() and mbox->geometry() are identical. Even though says and has a picture illustrating that the first is for the frame geometry while the second one is just about the interior of the mbox.

So it seems we can't get reliable information from the OS's frames though Qt. Until we get reliable information about the frame, it seems any attempt to compensate for the frame will be hopeless. So I don't know what we can really do about this problem.

I've discovered that running the following sequence of commands:

      QPoint displayPoint(0, 0);

will produce correct values for frame geometry vs client geometry.

I'm going to try to figure out the solution without any hack values...should be easy now that am actually getting values.

using <cpp>...</cpp> should make code samples readable

      QPoint displayPoint(0, 0);
Status PR created fixed

Fixed in branch master, commit 2f545c1c4a

_fix #277472 Tour mbox placement remember frame

Previously was problem with TourHandler failing to account for the thickness of its message box frame. Unfortuantely there doesn't seem to be an easy way to adjust the position according to the frame thickness, because the frame geometry isn't known until after the message box exec() runs...but since exec() halts execution, there isn't an easy way to adjust after it runs.

My solution is to remember the previous thickness values of the frame after each message box completes exec(), and then to use those stored values to calculate adjustments for the next time TourHandler needs to adjust placement of its message box._

Fix version