Tour dialogs overlap with the highlighted area

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.

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.

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.

I made that note in response to someone's PR attempt at a fix: https://github.com/musescore/MuseScore/pull/5171#issuecomment-505714735

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.

I've made my own PR: https://github.com/musescore/MuseScore/pull/5192

As I explained in the PR, since frame geometry isn't known until after exec() is run, what I've done instead is to remember the frame thickness from the prior time that TourHandler ran exec() for a messagebox, and then use that thickness to adjust the position.

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

      QPoint displayPoint(0, 0);
      mbox->move(displayPoint);
      mbox->show();
      mbox->exec();

thanks for that tidbit of info...would have never known had you not told me! :)

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

Fixed in branch master, commit b9afd1caf4

_Merge pull request #5192 from ericfont/277472-TourDialogPlacement

fix #277472 Tour mbox placement remember frame_

Automatically closed -- issue fixed for 2 weeks with no activity.