Bug 390642 - Cursor gets stuck with the wrong icon after moving between canvas and gui
Summary: Cursor gets stuck with the wrong icon after moving between canvas and gui
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Platform: macOS (DMG) macOS
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
: 374590 391379 392370 392400 394128 395126 396379 398906 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-02-17 21:42 UTC by Jonathan
Modified: 2019-04-05 09:46 UTC (History)
19 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Zooming with trackpad ends up with different zoom tool icon, stuck (722.35 KB, image/png)
2018-02-20 19:19 UTC, Jonathan
Details
Zoom icon prevails after zooming using gesture pinch (784.65 KB, video/mp4)
2018-02-21 00:22 UTC, vanyossi
Details
Stuck cursor (mouse pointer and window resize) (1.98 MB, video/mp4)
2018-09-20 06:52 UTC, Alberto
Details
Shell script to build the 3rd party dependencies on MacOS (1.23 KB, text/x-sh)
2018-12-31 20:31 UTC, Ahmad
Details
Shell script to build Krita on MacOS (480 bytes, text/x-sh)
2018-12-31 20:32 UTC, Ahmad
Details
Shell script to build the 3rd party dependencies on MacOS - FIXED (1.50 KB, text/x-sh)
2019-01-08 02:51 UTC, Ahmad
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan 2018-02-17 21:42:27 UTC
After zooming, the tool icon remains as the zoom icon (magnifying glass) and never returns to brush, hand, etc.
Comment 1 Halla Rempt 2018-02-20 08:23:34 UTC
Hi Jonathan,

If you mean you're zooming with the zoom tool, then you will need to explicitly select another tool after a zoom operation. Or do you mean something else?
Comment 2 Jonathan 2018-02-20 19:19:17 UTC
Hi,
I just double checked. When selecting the zoom tool, then switching to another tool, the icon does change. When I zoom in with the trackpad, a different zoom icon takes place and gets "stuck".
Comment 3 Jonathan 2018-02-20 19:19:55 UTC
Created attachment 110857 [details]
Zooming with trackpad ends up with different zoom tool icon, stuck
Comment 4 vanyossi 2018-02-21 00:20:24 UTC
I can reproduce this one. After the icon gets stuck the only way to restore to normal is to relauch application.

tested in OSX.

To reproduce:

Enter zoom mode, tool or shortcut.
make a pich gesture on trackpad

Result:
Zoom icon persists as user cursor for the rest of the session.
Comment 5 vanyossi 2018-02-21 00:22:18 UTC
Created attachment 110865 [details]
Zoom icon prevails after zooming using gesture pinch

Video showing the issue.
Comment 6 Halla Rempt 2018-02-22 09:56:35 UTC
Okay, then we can set this confirmed. I have no idea why this should happen, though...
Comment 7 Jonathan 2018-03-22 20:57:16 UTC
Bug still present in 4.0.0
Comment 8 Halla Rempt 2018-03-22 21:11:46 UTC
Well, yes... If have no idea how this could happen, a fix is unlikely to materialize :-)
Comment 9 Jonathan 2018-03-22 21:28:48 UTC
Sorry, wasn't complaining, just making a note because of the new release today. If I knew much about code I would poke around and try to help.
Comment 11 Jonathan 2018-03-23 21:56:43 UTC
Sorry to spam, but I noticed today that when I get in this state with a stuck zoom icon, it goes away if I move the cursor off of the canvas, then doesn't happen anymore in that session. Strange bug...
Comment 12 Halla Rempt 2018-03-26 16:11:11 UTC
*** Bug 392370 has been marked as a duplicate of this bug. ***
Comment 13 Halla Rempt 2018-03-28 12:07:10 UTC
*** Bug 392400 has been marked as a duplicate of this bug. ***
Comment 14 Halla Rempt 2018-05-11 13:54:45 UTC
*** Bug 394128 has been marked as a duplicate of this bug. ***
Comment 15 Halla Rempt 2018-06-08 08:19:05 UTC
*** Bug 395126 has been marked as a duplicate of this bug. ***
Comment 16 coffeecat 2018-08-16 18:12:38 UTC
Can I bump this? I really want to use krita on my macbook, and this issue is literally the only thing that stops me.
Comment 17 Halla Rempt 2018-08-16 18:26:35 UTC
I'm sorry, but no, you cannot "bump" this. Krita being an open source project is dependent on contributions to the code base to a large extent, and this is one place where we lack those contributions. We need more macOS fans to start hacking on Krita.
Comment 18 coffeecat 2018-08-16 19:03:01 UTC
(In reply to Boudewijn Rempt from comment #17)
> I'm sorry, but no, you cannot "bump" this. Krita being an open source
> project is dependent on contributions to the code base to a large extent,
> and this is one place where we lack those contributions. We need more macOS
> fans to start hacking on Krita.

that was unnecessarily aggressive. i am literally just saying that hey, *macos fan here* (like you want so much), i'd like to ask if there was any progress on this? if anyone has had any thoughts whatsoever on this? but no, you just had to go and be aggressive to one potential contributor. nice welcome to the community.
Comment 19 Halla Rempt 2018-08-16 19:52:26 UTC
I'm sorry, but I don't see how I was aggressive?
Comment 20 vanyossi 2018-08-16 21:56:54 UTC
There is a workaround if you have a mouse/trackpad. When the cursor gets stuck just move it with the trackpad/mouse. Not the best work around, but at least it lets me draw.

In general it seems Qt on OSX has a different approach for handling tablet events which causes this cursor bug to surface. I suspect it is rooted on Qt as I get a similar error on other Qt apps when using the tablet. But possibly there is something we can do to fix from Krita, but I haven't had the time to look into it.

boud wasn't been agressive, he was being informative. We do depend on contributions, so despite the bump we can't accelerate the rate this bug will be fixed. I do Krita hacking on OSX but I have yet to acquire the technical knowledge to understand this bug, Im sorry.
Comment 21 coffeecat 2018-08-16 22:05:24 UTC
Thanks for clarifying. I understand how open source projects work, so I misunderstood boude's tone. Saying "you cannot bump" sounded to me like "shut up" more than anything, so I'm sorry for misunderstanding.

Thanks for the info on QT's issue, it helps anyone looking into this (including me, and thus why I bumped in the first place) to know where to look.
Comment 22 Halla Rempt 2018-09-01 09:33:22 UTC
*** Bug 396379 has been marked as a duplicate of this bug. ***
Comment 23 achachinyachoke 2018-09-16 06:08:23 UTC
This is may be due to QT on mac as it seems to happen on Pencil2D too. https://discuss.pencil2d.org/t/stuck-curson-icons-on-mac-osx-when-using-tablet/1320
Comment 24 Alberto 2018-09-20 06:50:09 UTC
Hi, I am encountering this issue as well on Mac OS X 10.13.6 with the Wacom Intuos tablet.

Krita
  Version: 4.1.1

OS Information
  Build ABI: x86_64-little_endian-lp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: darwin
  Kernel Version: 17.7.0
  Pretty Productname: macOS High Sierra (10.13)
  Product Type: osx
  Product Version: 10.13

OpenGL Info
  **OpenGL not initialized**

I am attaching a movie with repro as it happens all the time now that I hooked up my tablet.
Comment 25 Alberto 2018-09-20 06:52:32 UTC
Created attachment 115111 [details]
Stuck cursor (mouse pointer and window resize)

No cursor should display per default setting.
Comment 26 Halla Rempt 2018-10-06 18:40:32 UTC
*** Bug 398906 has been marked as a duplicate of this bug. ***
Comment 27 vanyossi 2018-10-07 09:13:39 UTC
*** Bug 391379 has been marked as a duplicate of this bug. ***
Comment 28 Halla Rempt 2018-10-09 09:00:07 UTC
*** Bug 374590 has been marked as a duplicate of this bug. ***
Comment 29 Halla Rempt 2018-10-09 09:01:01 UTC
Wothera reports that this is reproducible under Linux now, if we disable our own xcb implementation.
Comment 30 speedyblueskyfish 2018-10-25 15:55:03 UTC
Hey, I am not sure if this is the same bug, but I am getting the "drag hand" icon stuck after moving the mirror on my canvas. I can draw, but the icon obscures my view and hinders drawing. relaunching fixes it. I think it sounds similar, but maybe i should report it as a separate bug? I'm on windows 10, krita 4.1.5. I did not have this issue in the previous version of krita.
Comment 31 Ricardo Franco 2018-10-28 09:28:20 UTC
I’m using Krita 4.1.5 on OS X Mojave. I’ve encountered many forms of this bug. Mainly the cursor turns from being the one I’m using (ie brush) to a pointer, a double sided arrow, or a magnifying glass and it disables me from using the brush. If it’s just a pointer or a double sided arrow, I have to lift my pen from the tablet and then it works. If it’s the magnifying glass, I can’t use any tools even if I lift my pen. I have to relaunch the app. The magnifying glass form of this bug is consistently triggered if I click on the trackpad with two fingers (like a right click) or sometimes if I pinch to zoom in/out from the canvas.
Comment 32 Halla Rempt 2018-10-31 14:36:00 UTC
Yes, we know... We just don't know how to fix this issue. Everybody is free to have a try!

(By the way, leave the version number alone: the meaning of that field is "reproducible from this version onward".)
Comment 33 Aaron Oldenburg 2018-12-30 18:36:48 UTC
The same thing happens to me on Manjaro Linux. At first, I had to open and close the program to get the right tool back.  Moving the cursor off of the canvas didn't help, as it did for another commenter.  However, when I grabbed the Toolbox and undocked it to its own separate window, then redocked it, the tool was back.  Hopefully this is helpful for someone.
Comment 34 Ahmad 2018-12-31 01:55:34 UTC
I've been doing some rudimentary debugging with info logs on MacOS. What I'm noticing is that with just the mouse or touch events on the Wacom tablet, when you move the cursor in and out of the canvas area it fires the QEvent::Enter and QEvent::Leave events correctly.

However, with the Wacom Pen it gets tricky. When you first hover the pen on the canvas it does QEvent::TabletEnterProximity. Now when you move the pen, while still hovering, out of the canvas area onto one of the widgets, it triggers the QEvent::Leave. However, now when you move the cursor back into the Canvas area, it will not trigger QEvent::Enter anymore. During this time it picks the last cursor shape change that occurs around the boundary of widgets. If you bring the pen down to draw, nothing gets drawn. Also, QEvent::TabletMove continues to fire regardless of whether the cursor is within bounds of any of the widgets in the UI.

While its messed up, if you move the pen far enough off the tablet QEvent::TabletEnterProximity gets triggered and when you move the pen back down it will trigger QEvent::Enter correctly which resets the tool cursor and followed by the QEvent::TabletEnterProximity. You can now draw normally until you move the pen out of canvas bounds again.


I'm still trying to follow what the code is doing as I haven't touched C++ in over a decade and not familiar with Qt and Krita. I'm wondering if there is some weird edge case in the application logic where the cursor/tool icons are shown/hidden and they need to take the status of the Wacom Pen being hovered/not.
Comment 35 Ahmad 2018-12-31 01:57:43 UTC
Correction. In the second last paragraph, if you move the pen far enough off the tablet QEvent::TabletLeaveProximity is fired.
Comment 36 Ahmad 2018-12-31 05:33:26 UTC
Another correction, the TabletMove doesn't happen outside the canvas area. Also, once the Leave event is triggered, both Enter/Leave will not be triggered when you move the pen around while hovering.
Comment 37 Ahmad 2018-12-31 05:45:17 UTC
This is also a problem reported for Qt: https://bugreports.qt.io/browse/QTBUG-65199?attachmentViewMode=list
Comment 38 Halla Rempt 2018-12-31 12:20:36 UTC
Oh, thank you! I'll update the macOS builds to 5.12.1 when it comes out, and then we can see whether this shows up as fixed in Krita. I wonder if this also fixes a similar bug in Linux that happens when we replace our own XCB code with Qt's
Comment 39 Ahmad 2018-12-31 20:31:37 UTC
Created attachment 117213 [details]
Shell script to build the 3rd party dependencies on MacOS
Comment 40 Ahmad 2018-12-31 20:32:09 UTC
Created attachment 117214 [details]
Shell script to build Krita on MacOS
Comment 41 Ahmad 2018-12-31 20:33:23 UTC
I don't know if this is the right place for it but I attached 2 shell scripts I use to automate the build process a bit so I don't have to continuously type all the cmake commands by hand. Might be useful for some others and can be easily tweaked to streamline the local development process.
Comment 42 Ahmad 2018-12-31 20:33:36 UTC
I tried using Qt 5.12 RC2 (https://download.qt.io/development_releases/qt/5.12/5.12.0-rc2/single/qt-everywhere-src-5.12.0-rc2.tar.xz.mirrorlist) to build Krita and it doesn't resolve the issue. It also causes the UI to go white until you resize the application window.

I did have to hack the diffs a bit to get it to compile. I'm wondering if I'm missing something.

For Linux, I'd have to setup a VirtualBox image and setup a bunch of things so it might take a lot longer to reproduce.

Anyway, will retry in the new year :)
Comment 43 Halla Rempt 2019-01-01 11:53:55 UTC
That's a pity :-(
Comment 44 Ahmad 2019-01-08 02:51:32 UTC
Created attachment 117339 [details]
Shell script to build the 3rd party dependencies on MacOS - FIXED
Comment 45 Ahmad 2019-01-08 17:25:47 UTC
Qt 5.12.0 was released and I was able to build against it with some minor fiddling again with the diffs.

I found that the UI going white happens when you enable the Canvas Graphics Acceleration (OpenGL). It might just be some backwards compatibility is broken.

As before, just updating Qt doesn't solve the bug with the tablet events. I'll take a look at what else might be the cause of the events not being triggered correctly.
Comment 46 Halla Rempt 2019-01-15 09:57:31 UTC
That sounds pretty bad, too, if opengl is broken again with Qt 5.12.
Comment 47 vanyossi 2019-03-14 03:46:27 UTC
It is solved for me on latest master and Qt 5.12.1 with xcb patches/changes from Dmitry. Cursor no longer gets stuck when going between GUI and Canvas. OpenGL Accel is enabled.

Coould you check this is the case by checking the dmg below? (link to google drive)

https://drive.google.com/file/d/1bdCJ7vZK8B-18bFdpDKa8R9fzdBd3-mE/view?usp=sharing
Comment 48 Ahmad 2019-03-14 23:02:57 UTC
@vanyossi I just tested the build with and without OpenGL Acceleration and it works perfectly. It also hasn't broken the UI (where it went all white with my patch). 

The only thing I did notice is that the brush cursor is very light against a white canvas when OpenGL Acceleration is enabled but the main problem with the cursor getting stuck and the tool not working is fixed.
Comment 49 zoltron 2019-03-22 23:57:52 UTC
(In reply to vanyossi from comment #47)
> It is solved for me on latest master and Qt 5.12.1 with xcb patches/changes
> from Dmitry. Cursor no longer gets stuck when going between GUI and Canvas.
> OpenGL Accel is enabled.
> 
> Coould you check this is the case by checking the dmg below? (link to google
> drive)
> 
> https://drive.google.com/file/d/1bdCJ7vZK8B-18bFdpDKa8R9fzdBd3-mE/
> view?usp=sharing

@vanyossi I just tested the build with and without OpenGL Acceleration and it doesn't work.
Comment 50 Halla Rempt 2019-03-24 12:26:07 UTC
Please specify your hardware and tablet brand when reporting the results of testing that build.
Comment 51 zoltron 2019-03-24 18:38:33 UTC
(In reply to Boudewijn Rempt from comment #50)
> Please specify your hardware and tablet brand when reporting the results of
> testing that build.

macbook pro 15 2016 with AMD Radeon Pro 455 / Intel HD Graphics 530
krita 4.1.7

Cursor gets stuck with the wrong icon after zooming with trackpad or mouse.
Comment 52 Ahmad 2019-03-24 21:10:57 UTC
Macbook Pro 13" (2017) w/ Intel Iris Plus Graphics 650 1536MB

macOS Mojave 10.14.3

Wacom Intuos Pro Medium PTH-651

Wacom Driver v6.3.32-3
Comment 53 vanyossi 2019-03-25 20:10:52 UTC
@zoltron

If the version stated in "Krita:About" is 4.1.7, you were not using the dmg I provided as it reads 4.2.0-beta (or something similar).

The bug you are getting seems to be another one about the cursor getting stuck after zooming or rotating with touchpad gestures. It should not get stuck by simply moving the cursor between canvas and docker elements. If it gets stuck only by "moving the cursor around the interface with the tablet" then the bug is still present.
Comment 54 zoltron 2019-03-25 20:32:44 UTC
(In reply to vanyossi from comment #53)
> @zoltron
> 
> If the version stated in "Krita:About" is 4.1.7, you were not using the dmg
> I provided as it reads 4.2.0-beta (or something similar).
> 
> The bug you are getting seems to be another one about the cursor getting
> stuck after zooming or rotating with touchpad gestures. It should not get
> stuck by simply moving the cursor between canvas and docker elements. If it
> gets stuck only by "moving the cursor around the interface with the tablet"
> then the bug is still present.

sorry you are right, this happens only when zooming with touchpad gesture, i tried with every versions of krita. bug is not fixed any version.
Comment 55 zoltron 2019-03-25 20:45:37 UTC
(In reply to zoltron from comment #54)
> (In reply to vanyossi from comment #53)
> > @zoltron
> > 
> > If the version stated in "Krita:About" is 4.1.7, you were not using the dmg
> > I provided as it reads 4.2.0-beta (or something similar).
> > 
> > The bug you are getting seems to be another one about the cursor getting
> > stuck after zooming or rotating with touchpad gestures. It should not get
> > stuck by simply moving the cursor between canvas and docker elements. If it
> > gets stuck only by "moving the cursor around the interface with the tablet"
> > then the bug is still present.
> 
> sorry you are right, this happens only when zooming with touchpad gesture, i
> tried with every versions of krita. bug is not fixed any version.

i use dmg you provided. your dmg crashed when "split alpha" operation.
Comment 56 Dustin Wilson 2019-03-30 05:00:36 UTC
I tried the 4.20 alpha DNG that was provided, and I painted for a good two hours tonight with it with no issues concerning the cursor using a Wacom Intuos 4 XL on macOS 10.13.6 with an Nvidia GeForce GTX 1060.
Comment 57 Halla Rempt 2019-04-05 09:46:14 UTC
Setting to fixed then. The crash with split alpha has nothing to do with this report, of course.