Tour dialogs overlap with the highlighted area

• Oct 26, 2018 - 09:22
Reported version
3.0
Priority
P2 - Medium
Type
Functional
Severity
S4 - Minor
Status
PR created
Regression
No
Workaround
No
Project

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_20181026_111740.png
Screenshot from:
OS: Debian GNU/Linux 9 (stretch), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: de93ba1


Comments

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: https://github.com/musescore/MuseScore/blob/master/mscore/tourhandler.c… , 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: http://doc.qt.io/qt-5/qwidget.html#size-prop . 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:
tours_palette.png
Tour for a timeline indeed has some gap between the dialog window and the highlighted area:
tours_timeline.png

A note I made in telegram:

I'm looking at https://doc.qt.io/qt-5/application-windows.html#window-geometry 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 https://doc.qt.io/qt-5/application-windows.html#window-geometry 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);
      mbox->move(displayPoint);
      mbox->show();
      mbox->exec();

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);
      mbox->move(displayPoint);
      mbox->show();
      mbox->exec();