Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
6.5.0
-
None
-
-
8c0153a52 (dev), 9e7f1f3e5 (6.5)
Description
There is a risk that this is more (behavior related) issues, but the bottom line is that QMenu has some size issues. I have been unable to boil the observed bugs down to a simple code example, but the system with two screens (with different dpi) appears to be central to reproduce (see attached qtdiag.txt) and problems can be seen in Qt Creator
a) Typically a first-show issue (when shown on the)
b) Not as easy to get as (a), but it is still common. The menu are shown on the same screen (without anything happening in between). However, there is a mismatch in size and spacing. (13 items in Build menu matches 16 items in edit menu - despite the more separator items in the latter).
Regarding point (b), I have in another program tracked down a strange behavior in QSize QWindowsVistaStyle::sizeFromContents ( qwindowsvistastyle.cpp ).
case CT_MenuItem: { ..... (code) .... const QSizeF size = themeSize.size() * QWindowsStylePrivate::nativeMetricScaleFactor(widget);
Here the result of themeSize.size() is not consistent for same items which would be expected. However, it appears not to be the codepath for Qt Creator is in. Therefore, I suspect the QMenu somehow can catch some wrong screen/state mismatch.
PS:
I found a way to reproduce an issue a bit similar to (b). Open attached 'trivial' example menuSizeIssue.zip (in Creator). The program starts where the mouse is. If the menu starts on the low high dpi display there is nearly no space between the items in the menus. If the menu starts on the high dpi display there is (too) much space between the items. In both situations the situation does not change on space when moving it to the other screen.