After zooming, the tool icon remains as the zoom icon (magnifying glass) and never returns to brush, hand, etc.
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?
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".
Created attachment 110857 [details]
Zooming with trackpad ends up with different zoom tool icon, stuck
I can reproduce this one. After the icon gets stuck the only way to restore to normal is to relauch application.
tested in OSX.
Enter zoom mode, tool or shortcut.
make a pich gesture on trackpad
Zoom icon persists as user cursor for the rest of the session.
Created attachment 110865 [details]
Zoom icon prevails after zooming using gesture pinch
Video showing the issue.
Okay, then we can set this confirmed. I have no idea why this should happen, though...
Bug still present in 4.0.0
Well, yes... If have no idea how this could happen, a fix is unlikely to materialize :-)
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.
Though this line is interesting...
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...
*** Bug 392370 has been marked as a duplicate of this bug. ***
*** Bug 392400 has been marked as a duplicate of this bug. ***
*** Bug 394128 has been marked as a duplicate of this bug. ***
*** Bug 395126 has been marked as a duplicate of this bug. ***
Can I bump this? I really want to use krita on my macbook, and this issue is literally the only thing that stops me.
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.
(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.
I'm sorry, but I don't see how I was aggressive?
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.
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.
*** Bug 396379 has been marked as a duplicate of this bug. ***
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
Hi, I am encountering this issue as well on Mac OS X 10.13.6 with the Wacom Intuos tablet.
Build ABI: x86_64-little_endian-lp64
Build 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 not initialized**
I am attaching a movie with repro as it happens all the time now that I hooked up my tablet.
Created attachment 115111 [details]
Stuck cursor (mouse pointer and window resize)
No cursor should display per default setting.
*** Bug 398906 has been marked as a duplicate of this bug. ***
*** Bug 391379 has been marked as a duplicate of this bug. ***
*** Bug 374590 has been marked as a duplicate of this bug. ***
Wothera reports that this is reproducible under Linux now, if we disable our own xcb implementation.
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.
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.
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".)
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.
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.
Correction. In the second last paragraph, if you move the pen far enough off the tablet QEvent::TabletLeaveProximity is fired.
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.
This is also a problem reported for Qt: https://bugreports.qt.io/browse/QTBUG-65199?attachmentViewMode=list
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
Created attachment 117213 [details]
Shell script to build the 3rd party dependencies on MacOS
Created attachment 117214 [details]
Shell script to build Krita on MacOS
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.
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 :)
That's a pity :-(
Created attachment 117339 [details]
Shell script to build the 3rd party dependencies on MacOS - FIXED
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.
That sounds pretty bad, too, if opengl is broken again with Qt 5.12.
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)
@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.
(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
@vanyossi I just tested the build with and without OpenGL Acceleration and it doesn't work.
Please specify your hardware and tablet brand when reporting the results of testing that build.
(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
Cursor gets stuck with the wrong icon after zooming with trackpad or mouse.
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
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.
(In reply to vanyossi from comment #53)
> 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.
(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.
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.
Setting to fixed then. The crash with split alpha has nothing to do with this report, of course.