Bug 364850 - (Qt 5.7) If any docker is in focus e.g. layer docker , canvas zoom function with mouse scrollwheel is gone. The contents of the dockers is scrolled instead of canvas zoom
Summary: (Qt 5.7) If any docker is in focus e.g. layer docker , canvas zoom function w...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
: 369482 Grean (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-06-28 10:06 UTC by Raghavendra kamath
Modified: 2017-08-14 10:09 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Raghavendra kamath 2016-06-28 10:06:54 UTC
When the layer docker gets a scrollbar and user clicks on any one of the layer, canvas zoom with the scroll wheel is not possible as the layer docker is scrolled instead. as if the focus of the mouse is in the layer docker even when the user has clicked on the canvas.

Reproducible: Always

Steps to Reproduce:
1.open an image with many layers so and arrange the layer docker so that it has a scrollbar
2.click on any one of the layer 
3.now try to zoom the canvas with the mouse scrollwheel

Actual Results:  
the layer docker is scrolled instead of the canvas zoom function

Expected Results:  
when the user clicks or returns to canvas, user should be able to use mouse scrollwheel to zoom in and out of the canvas

in my opinion this may be somehow related to this bug report -> https://bugs.kde.org/show_bug.cgi?id=363043
Comment 1 Raghavendra kamath 2016-06-28 10:08:14 UTC
I noticed this just now.

this can be reproduced with any docker having a scrollbar
Comment 2 Bollebib 2016-06-29 16:19:33 UTC
for my system it seems to work fine

Maybe it's a linux only issue? Can you test it out on a windows rig just to compare?
Comment 3 Eevee 2016-07-04 21:48:34 UTC
The mouse wheel no longer works for scrolling any other docker, either.  Even if the layers docker isn't visible.  Even if you close the image with many layers and switch to an image with only one layer!  I can't find any way to fix this once it's happened, either, other than closing and reopening Krita.

Also on Linux.
Comment 4 Eevee 2016-07-04 22:17:44 UTC
Aha, actually, I don't think the problem is clicking.  If you use the mouse wheel to scroll the layers docker (or the brush presets docker, or probably others), any further use of the mouse wheel /anywhere/ will go to that same docker.  No clicking is necessary.

This probably isn't as noticeable on Windows because (iirc) Windows interprets the mouse wheel as scrolling whatever has focus, whereas Linux scrolls whatever's under the cursor.
Comment 5 Loren Dias 2016-07-05 01:53:50 UTC
I've confirmed this on Krita on two Arch Linux boxes.

For me the problem seems to default to scroll being set to the "Browse" docker I have opened.

I'm going to make a assumption that it defaults alphabetically to a docker eg:
1. Browse
2. History
3. Layers
...etc

I'm going to assume that somewhere in the code it has to enable  :focus on the Canvas box. It's as if the active box doesn't change with the mouse hover or on mouse click either.

Confirmed on both Linux boxes Krtia 3.0-1
Comment 6 Halla Rempt 2016-07-05 13:32:16 UTC
I suspect it's a Qt version problem or a window manager problem. Can you please check whether the appimage also shows this behaviour for you?
Comment 7 Raghavendra kamath 2016-07-05 14:31:12 UTC
Boud i think you are right. I made a mistake of not stating my qt version. My qt version is 5.7
I tested the appimage as well as 3.0 from repositories which don't have this issue, so yes I think you are right about qt version issue
Comment 8 wolthera 2016-07-05 16:47:54 UTC
uhm, actually, as far as I know this is intentional behaviour. Dmitry specifically set the canvas input settings to stop activating if a docker is in focus.
Comment 9 Raghavendra kamath 2016-07-05 16:53:42 UTC
@wolthera the focus is not on canvas even after we click or paint on it.
Comment 10 Maksymilian Świąć 2016-07-13 22:32:11 UTC
Allegedly, this is a Qt 5.7 problem (which is now available in Arch Linux repos) - Krita built with Qt 5.6 supposedly does not have this problem. (I say 'supposedly' because I'm experiencing this problem as well and I only have Qt 5.7 installed.)
Comment 11 wolthera 2016-07-14 10:48:20 UTC
If you try out the appimage, which has QT 5.6, you could verify that. If the bug happens in the appimage, then it's not qt5.7's fault.
Comment 12 Raghavendra kamath 2016-07-14 11:40:52 UTC
I already tried the appimage this behavior is not reproducible in it.
Comment 13 animtim 2016-07-22 18:05:10 UTC
I confirm this bug happens with Qt 5.7.0.
Comment 14 wolthera 2016-10-04 17:01:40 UTC
*** Bug 369482 has been marked as a duplicate of this bug. ***
Comment 15 Eevee 2016-11-17 20:25:30 UTC
This also happens with the scrollable list in the "recover documents" dialog: if I scroll it with the mouse wheel, the mouse wheel no longer works anywhere else, even after closing the dialog.
Comment 16 Nicholas LaPointe 2016-12-21 01:50:43 UTC
The change in Qt that causes this is here: http://code.qt.io/cgit/qt/qtbase.git/commit/?id=f253f4c3310655933266f62e90f46fd12b5c49e4
Comment 17 Halla Rempt 2016-12-21 13:06:34 UTC
Good find! Now we can report a bug with the qt project.
Comment 18 Shawn Rutledge 2017-02-06 09:04:28 UTC
Please make sure you get around to reporting that Qt bug.
Comment 19 supaiku 2017-06-04 21:58:58 UTC
Can someone tell if this issue got fixed with Qt 5.9?
Comment 20 Halla Rempt 2017-06-05 09:23:40 UTC
*** Bug 379058 has been marked as a duplicate of this bug. ***
Comment 21 Nicholas LaPointe 2017-06-05 13:14:06 UTC
I tested with Qt 5.9 and the same issue occurs.
I'm not certain that this is a Qt bug, which I mentioned on IRC a while back:
>09:27:17 < nicholasl> boud: Regarding bug 364850, is that really a Qt bug? The description in this (reverted for Qt 5.7) commit makes it seem like the behavior is expected with older applications: http://code.qt.io/cgit/qt/qtbase.git/commit/?id=d5fde514106f5479f9c929c8a165aced4a1b2c84
>09:33:41 < nicholasl> boud: It was reverted in http://code.qt.io/cgit/qt/qtbase.git/commit/?id=96740193e1e0f0608f67660811a44b696924ad4c and Qt::NoScrollPhase is now documented
Comment 22 Halla Rempt 2017-06-06 08:56:00 UTC
I'm not sure whether I understand those two links...
Comment 23 Nicholas LaPointe 2017-06-06 20:29:23 UTC
Git commit 9bec9bb20d9b593ed4a3194dce11bc5191c9bea5 by Nicholas LaPointe.
Committed on 06/06/2017 at 20:27.
Pushed by nicholasl into branch 'master'.

Fix scroll wheel behavior when using Qt 5.7 or later

M  +5    -0    libs/ui/input/wintab/qxcbconnection.cpp
M  +4    -0    libs/ui/input/wintab/qxcbconnection_xi2.h

https://commits.kde.org/krita/9bec9bb20d9b593ed4a3194dce11bc5191c9bea5
Comment 24 Raghavendra kamath 2017-06-07 04:15:37 UTC
Wow! Thank you very much Nicholas LaPointe.

For me this is working now with qt 5.8 on arch linux.
Comment 25 Halla Rempt 2017-06-07 07:24:16 UTC
On OSX, with a real mouse wheel (logitech mouse, not one of apple's), everything is fine. Two-finger zoom on the trackpad goes crazy, though, it tries to effect a zoom for every % or tenth of % between two states, and a small movement goes from 100 to 1600%. This is a bit of a regression, so maybe we need more ifdeffery?
Comment 26 Nicholas LaPointe 2017-08-14 10:09:06 UTC
Git commit a5d38006fb0bd86c661516704a435b80688d6f9c by Nicholas LaPointe.
Committed on 14/08/2017 at 10:08.
Pushed by nicholasl into branch 'krita/3.2'.

Fix scroll wheel behavior when using Qt 5.7 or later

M  +5    -0    libs/ui/input/wintab/qxcbconnection.cpp
M  +4    -0    libs/ui/input/wintab/qxcbconnection_xi2.h

https://commits.kde.org/krita/a5d38006fb0bd86c661516704a435b80688d6f9c