Created attachment 90208 [details] trojita-qt5-small-hit-region.png With Qt 5.3.2, the pane that lists messages in a mailbox behaves in a weird manner. In Qt4, I can click on any part of the entire row (except the green dot which triggers read/unread status), and a mail will open. However, in my Qt5 build, this only works on a small region to the extreme left. The visual highlight fortunately matches this behaviro, see the attached image. I recall that there was a bug due to the way Qt5's QAbstractProxyModel changed the rules, so maybe there's something similar at play. Does anybody else also see this on Qt5?
I can't see this behaviour with Qt 5.3.2 on an Arch Linux machine.
Not here either (Qt 5.4.0, Archlinux) That's not fusion, is it? What about "trojita -style fusion"?
No difference with `trojita -style fusion`.
I see a similar behavior on the Qt4 version as well, after all (Qt 4.8.5, X11). I'm using View -> Layout -> Wide, and the columns which I have visible, left-to-right, are: - attachment indication - subject, - flagged status, - green dot for "seen", - from, - date, - size The mouse reacts to events from the very left, with a brief interruption over the threading collapse/expand widget, and stops somewhere in the middle of "from" (always at the same Y coordinate for all possible strings in that field). My Oxygen style is configured to paint a light blue highlight as I move the cursor over these, and that thing disappears as soon as I move my mouse too much to the right. There's a gap in this highlight for the thread collapse/expand widget *and* roughly the same space to the right, but that gap catches the mouseovers, unlike the region at right. -> Seems that we are doing something fishy.
Nope. I'd assume the weird header layout (w/ subject being the ultimately expanding one) could be the cause, but I do not get such issues here. As you said: No difference with `trojita -style fusion`. This means "I got the fusion style, but it shows the same problem", not "I'm still using the oxygen style here", does it? In "oxygen-settings" on the very first page, there's an option "Enable extended resize handles" Is that enabled on your side? What if you disable it? What about "Windows' drag mode" (set it to "titlebar only") What if you disable animations? (All this intercepts mouse events...)
> This means "I got the fusion style, but it shows the same problem", not "I'm > still using the oxygen style here", does it? Sorry, I've been apparently using the Fusion style with the Qt5 version all the time. Running the Qt5 trojita with `--style oxygen` or `--style windows` actually ucases a visual difference, but `--style fusion` or `-style fusion` doesn't (that looks like a default). I'm on a KDE4 desktop, and my Qt5 installation is a custom one. To the best of my knolwedge, I've only used Trojita-Qt5 and some Qt demos, not any other Qt5 application. > In "oxygen-settings" on the very first page, there's an option > "Enable extended > resize handles" > Is that enabled on your side? Yes > What if you disable it? No change in behavior of Qt4 and Qt5 versions. > What about "Windows' drag mode" (set it to "titlebar only") Done, no change. > What if you disable animations? No difference, either.
Happens here as well, Qt4 + 5, style is irrelevant. Just the dead area is no "very small" but a pretty tiny range on the outer right (width does not seem to depend on header section sizes and crosses the header) Well... we can fix what we can see ;-)
Seems that deleting all the sinzeInMainWin* data from the config file restores sane behavior again (I do have a backup). The next step is adding some debugging to check what exactly causes this. I hope I'll get around to that on Monday.
That code stinks, and I very likely don't have these old configs around anyway. Let's screw me.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!