mypaint icon indicating copy to clipboard operation
mypaint copied to clipboard

Published 20 hours ago • verified publisher icon mypaint

Mouse becomes unresponsive after switching windows

Open don570 opened this issue 6 years ago • 9 comments

Basic system details

MyPaint version: mypaint-git-w64-2.0.0-alpha-master.461-installer Operating system: windows 10 pro 64 bit Wacom bamboo tablet with latest windows driver.

Mouse becomes unresponsive after switching windows . This was reported by someone in 2015. But I'll report again.

Steps to reproduce

  1. Launch mypaint and then launch Microsoft paint program (or GIMP) and begin painting in window with tablet stylus.

  2. Switch to mypaint window and start to paint with stylus. Everything seems fine.

  3. I try to use mouse in mypaint window and there are severe limitations. i.e. popup brush label text won't show (with a mouse click) and paint won't show when I try to paint with mouse, but stylus still works fine.

  4. If I want to use my mouse in mypaint again I must quit mypaint and launch mypaint again.

don570 avatar Feb 14 '19 23:02 don570

This is only seen in windows 10. I tested a linux install (fatdog64) and I didn't see this problem.

don570 avatar Mar 03 '19 19:03 don570

I checked mypaint-git-w64-2.0.0-alpha-master.480-installer.exe in windows 10 and there is the same problem.

However one more observation .... I installed the latest Krita paint program https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/

and I was able to switch back and forth between mypaint and krita windows, and the mouse was still responsive.

This problem doesn't exist in Linux.

don570 avatar Mar 20 '19 22:03 don570

The problem happens every time when you tab to another window while the pen is close enough to the tablet to still influence the mouse pointer. If you raise it before tab'ing away it doesn't happen. And after that it no longer accepts any mouse-clicks, neither for drawing nor for menu-clicks. My test also on Windows 10 with version 2.0.0-alpha+git.869de4eb

mzeilfelder avatar Nov 08 '19 12:11 mzeilfelder

The gtk3-demo axes test also exhibits this behavior, so it appears to be an upstream issue.

calwas avatar Aug 26 '20 09:08 calwas

This issue is fixed in GTK merge requests #2501 and #2502.

calwas avatar Aug 29 '20 09:08 calwas

I still have this (or a similar) problem. What is the status on this one?

Using version 2.0.1+git.478280f2 on win10 64

einarpersson avatar Nov 08 '20 15:11 einarpersson

I still have this (or a similar) problem. What is the status on this one?

Using version 2.0.1+git.478280f2 on win10 64

calwas' merge requests linked to above have not been merged yet (though recent activity on the first one suggests it might be merged soon).

After that happens (assuming it does) it's a question of when the next patch-level release of Gtk will be. It might not happen in time for MyPaint v2.1.0

jplloyd avatar Nov 08 '20 16:11 jplloyd

The GTK project seems to put a low priority on updating its Windows support. I have four GTK merge requests, including the two linked above, that have been waiting two months for action. To worsen the situation, subsequent commits to GTK have introduced merge conflicts for the linked MRs that fix this issue. Given the MRs lack of attention, I am reluctant to resolve the conflicts only to have the updated MRs continue to sit around indefinitely. Not a good situation.

calwas avatar Nov 08 '20 19:11 calwas

Update: My fix for this issue was just merged into the GTK+3 branch. (Merge of the fix into GTK4 is still pending.) GTK v3.24.26 was released a few weeks ago, so the fix should be in the 3.24.27 release.

calwas avatar Mar 05 '21 23:03 calwas